OpendTect overviewIntro | Modules | Starting
OpendTect is a C++-based environement. A couple of years ago, C++ was declared dead by many as a result of the Java hype. In some areas, Java is indeed far better suited. In our part of the world (geosciences, in particular geophysics-related), we don't think Java can match the advantages of C++: Fast yet flexible, Low-level yet supporting high-level OO constructs. And, we would be terrified having to program without templates.
That doesn't mean that programming in C++ automagically delivers good software, and neither that performance comes easy. Those are some of the things that can be reached by a good design.
There are many aspects of software that can be categorised as 'good'. These include robustness, flexibility, high performance, compactness, maintainability, understandability. Software engineering is all about making choices - every aspect costs resources and there's always a limit to that. So, even if one tries to optimise all 'good' aspects, there will be different degrees of emphasis on each of them.
As OpendTect was developed in a research-minded environment, flexibility is a high priority. The Object-Oriented toolkit delivers many tricks to make software more flexible. Some of these tricks nowadays have labels - 'Design patterns' - like the ones in the 'Design Patterns' book (Factories,Singletons,etc.). Many constructs in the software are fit to match the problem though, always with a number of design principles in mind:
The last two are, [cough] of our own making. DIF ensures that there are no large amounts of unused code lying around to be maintained, NBS delivers a system that is as simple as possible given the constraints.
You may also want to look at the design/coding rules.
Isolation of external services
When services from another package (Qt, OpenSceneGraph, ...) are used, there is always an isolating layer - either a complete module or a class that uniquely uses those services. For software engineers this is an obvious action were it only to reduce the dependency problems.
There is however more to it. External services tend to be designed for much more general purposes than what is needed by OpendTect. Furthermore, some services that will be very important for us won't be available. And, we may not like the form in which the services are presented; moreover, the data structures used in the external package seldomly fit nicely with ours.
To overcome all this, and get a nice insulation at the same time, all external services are embedded in service layers that:
Isolation like this is present for a variety of subjects, from threads, sockets, file handling to User Interface building and Data loading.
OpendTect is based on a couple of external packages, which are mostly open source. These include:
A group of classes that handle a certain area of our domain is what could be called a module. Sometimes these modules have their own namespace, most often not (sometimes because the code pre-dates good support of namespaces by gcc). In any case, it does correspond with two physical directories in the source tree: include/module_name and src/module_name. Thus earth model related classes go in the
The separation of
Another separation that is very important is between UI- and 'Real Work' modules. No (direct) user interface work is done in the RW-modules. The amount of Real Work in the UI modules is minimised. Within the user interface part, there is a separation between basic UI (Qt-based in OpendTect) and 3D visualistion (OpenSceneGraph-based). Both types of user interface modules have a prefix: 'ui' and 'vis' respectively.
Making all these modules as opposed to just dumping everything in one big directory does have the effect that it becomes necessary to precisely know what's dependent on what. That's exactly what's described in the
First of all, there are the
In any case,
The domain-specific modules like
For most of the RW-modules, there is a UI counterpart. This is made possible by the basic UI modules
The OpenSceneGraph-based visualisation services are made available in the
It all comes together in the
Starting the programming
Before you start, get a good development environment by using the 'Utilities-Create Devel. Env.' menu. When that's finished, you must run CMake. Then you should be able to start developing right away.
Making it happen
Along the way, you'll have to do some digging in the include directory or the class documentation to figure out what services are available. You probably won't want to miss the info from the UNIX or windows instruction documentation. The plugin manual, well, see for yourself. If all you want to do is make batch programs, try batch program doc. And if all else fails, you may even consider sending an e-mail to email@example.com .