Dr. Dobb's Journal - October 2007 - (Page 45)

for its simplicity and expressiveness—most, if not all, high-level data types can be represented as a collection of named properties. Each Model has two implicitly defined properties: an id, which uniquely identifies the Model; and a type, which identifies the high-level data type of the Model. Beyond these two implicit properties, Models can have an arbitrary number of other properties. Models are also hierarchical in nature and may contain nested Models, indicating a parent-child relationship. This data model is flexible enough to be serialized to many different representations. PSICAT currently records the data model as an XML file using something like Example 1. However, there are two oddities in Example 1. First, if the data model is hierarchical and XML is hierarchical, why is the XML representation of the data model flat? During the development of PSICAT, I ran into a situation where deeply nested model trees were overflowing the stack because of too much recursion when parsing the data. In response, I switched to this flat structure, then “treeified” the data model after parsing. The second is less an oddity and more a limitation of the data model and XML serialization. In Example 1, no type information is persisted about the individual properties. This means the value “number” is just as valid as “1.12” for the depth.base property. This can cause problems when a property value represents a data type other than a character string—a number, for instance. To address this, PSICAT applies a mapping action where it maps the generic Model object to a specialized subclass of Model based on the value of the type property. This specialized Model is still backed by the associative array but can define helper methods; for instance, double getBaseDepth() and void setBaseDepth(double depth), for accessing the property values using native data types. useful to the broader geoscientific community, rather than just a one-off, custom solution developed for ANDRILL. Since this is an ambitious and complicated undertaking, I needed a flexible, extensible software architecture that would let me reuse functionality common to all drilling projects, while still supporting the development of custom features for specific groups or tasks. As a Java developer, I looked no further than Eclipse (www.eclipse.org) for my architecture solution. Known as a Java IDE, Eclipse is a full-blown platform of tools and frameworks for developing and managing software. Built on OSGi technology, Eclipse takes the concept of a modular architecture to the extreme. Traditional applications, such as web browsers, provide well-defined interfaces and extension mechanisms that you can plug into and add new functionality. The host application is fully functional; the plugins simply augment it with new features. Eclipse, on the other hand, is built entirely of plug-ins. There is no host application per se, Software Architecture Core description is a complex process to model in software. It involves data capture, visualization, analysis, collaboration, revision, and publication, with different features required for each step. To complicate things further, I wanted PSICAT to be October 2007 l www.ddj.com l Dr. Dobb’s Journal 45 http://www.eclipse.org http://www.slickedit.com/trial http://www.slickedit.com/trial http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - October 2007

Cover Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook AI: It’s OK Again! Conversations Visual Cryptography and Bit-Plane Complexity Segmentation Inside the Windows Vista Disk Encryption Algorithm Memory-Aware Components Software and the Core Description Process Logging In C++ Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - October 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.