Impedance Mismatches among Relational tables, Objects, and XML Hierarchy

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that undo the damage done by normalizing the original object model into multiple tables.

With the object paradigm, you traverse objects via their relationships whereas with the relational paradigm you join the data rows of tables. Scott Ambler has a good discussion of the Object-Relational Impedance Mismatch. He also describes The Cultural Impedance Mismatch Between Data Professionals and Application Developers (e.g.  "Data professionals that claim that your object/component models must be driven by their data models"), Why Data Models Shouldn't Drive Object Models (And Vice Versa).

What about XML hierarchies and database tables. Here's a good article on storing trees in tables. How do you store a tree in a database table?  He discusses a couple of challenges with typical approaches and presents a novel approach.

Some issues in the XML to Objects mapping: Revealing the X/O impedance mismatch (Changing lead into gold). In general I love working with JAXB and it is now part of the JDK. It's a breeze to auto-generate classes from XML schema that can then be used to import and export XML from your code. Strangely, there's a lack of up-to-date tutorials on using xjc from Java 6 or later. I will add that to my todo list.

"I believe the fundamental problem with the database solution comes from the fact that it is often slapped on an application by default. “We need persistence.” “Well, let’s use a database [and the ORM]“. is a good quote from Best alternative to RDBMS and ORMs : Terracotta | Taranfx: Technology Blogbase [and the ORM]“.

Other links:

• Object-relational impedance mismatch - Wikipedia, the free encyclopedia
• ORM - The Leaky Abstraction
• Inheritance vs Relational Databases in RoR
• Implementing Type hierarchies "There are three common patterns for mapping type hierarchies to database tables. Martin Fowler uses the following names for these patterns: Single Table Inheritance, Class Table Inheritance, and Concrete Table Inheritance"
• How XML Threatens Big Data : Dataspora Blog "Data lives in relational databases or as data structures in programs. The common import and export formats of these environments do not resemble XML, so much effort is dedicated to making XML fit. When more time is spent on inter-converting data — serializing, parsing,translating — than in using it, you’ve created a data bureaucracy."

Impedance Mismatches: Relational, Objects, and XML Hierachical

So often, we as software developers, try to map objects to a persistent relational database and run into difficulties because it just doesn't fit right. We end up working with ORM abstractions (e.g. Hibernate) that often seem more trouble than they're worth. This is what we call impedance mismatch.

Part of the problem is often letting the

Lean Software Development

Zero Practices (These practices that must be in place before taking the first step):

• Source Code Management
• Scripted Build

Daily Standup

Automated Testing

Continous Integration

• Use a dedicated build machine
• Check code changes into the repository a minimum of once a day (per developer); once an hour or more is even better.
• Immediately address any failures in the build. Fixing the build takes precedence over further implementation.

Less Code

• Eliminate Unnecessary Code
• Use coding standards to write readable and understandable code.
• Design and implement code with design patterns, refactoring, and emergent design.

Short Integrations

• Use Customer Feedback
• Course correction

Customer Participation

• Requirements Prioritization
• Acceptance Tests
• Accessible Status
• Access To Product

OSGi Evangelism and OO Design Principles

OSGi adds a higher layer of granularity to OO abstraction, information hiding, design by contract, etc. I like this quote  from Modular Mind: "Software development has advanced in large part by increasing the granularity of the aggregations that we have to work with.". In this presentation, Module Systems and Architectures, on OSGI, Martin Lippert also shows another evolution that can be seen in OSGi:


Good Old Design Principles
DIP SOC LSP ADP TDA DRY AIP
ISP SCP OCP IHP SRP SDP

New Design Principles
Use services ---> Separate between interface and implementation
Use extensions ---> working but extensible

Here's a breakdown of Martin's shortlist of "good old design principles":

Class Design Principle

• Separation Of Concerns (SoC)
• Tell, Don't Ask (TDA)
• Don't Repeat Yourself (DRY)
• Dependency Injection Principle (DIP)
• Liskov Substitution Principle (LSP)
• Open Closed Principle (OCP)
• Single Responsibility Principle (SRP)
• Interface Segregation Principle (ISP)

Package Design Principles

Cohesion Principles: 

• Reuse/Release Equivalency Principle (REP)
• Common Reuse Principle (CRP) 
• Common Closure Principle (CCP)

Coupling Principles:

• Acyclic Dependencies Principle (ADP)
• Stable Dependencies Principle (SDP)
• Stable Abstractions Principle (SAP)

  Object-Oriented Reengineering - Principles of OOD - Radu Marinescu,
  OO Design Principles - Stefan Kluth,

Emergent Design

TODO:

• Tracer Bullet Development (see Ship It, ch. 4)

• do light-weight, up front design, create a system of mock objects, and add appropriate automated tests
• System Objects: Encapsulate and Separate 
• incrementally add functionality to the system  
• Incremental Improvements: Iterations
• benefits: scalability, encapsulation, decoupled code, parallel code development, flexible to requirements creep

Static Code Analysis, Defect Detection, Code Smells, Architecture Smells, Dependency Analysis

FindBugs Descriptions

• Bad Practice
• Correctness
• Experimental
• Malicious Code Vulnerability
• Multithreaded Correctness
• Performance
• Security
• Dodgy Practices

PMD Rulesets

Lint4J checks for

• Architectual problems
• Contracts defined in the Java core API
• Java Language Constructs
• Immature code
• Performance
• Code portability
• The Serialization and Externalization contracts
• Suspicious coding and likely bugs
• Java Synchronization and Scalability
• Coding patterns that impact readability and code size
• Violations of the EJB specification

JLint Program Checker

Coverity Static Analysis, Dynamic Analysis , Architectural Analysis

NASA's JPF (Java Path Finder)
Which defects can be found by JPF? Out of the box, JPF can search for deadlocks and unhandled exceptions (e.g. NullPointerExceptions and AssertionErrors), but the user can provide own property classes, or write listener-extensions to implement other property checks. A number of such extensions, like race condition and heap bounds checks are included in the JPF distribution 

Hammurabi Hammurapi is a code quality governance platform to mitigate risks of outsourcing* of software development.

Structure 101