There has long been a fairly significant level of confusion over the fundamental difference between Structured Development (SD) which by definition implies an internal functional viewpoint and Object Oriented Development (OOD) which implies an external object viewpoint.

Unfortunately, the confusion has been fueled by a host of articles penned by authors touting their own personal slant to the subject, emphasizing what they view as important and supportive of their perspective and de-emphasizing the rest.

The real question today is if OOD is in fact a better development strategy than SD. The support for this claim is twofold. First, the object viewpoint is a more natural view of the world than the functional viewpoint. Objects are somehow a more natural way for the human mind to conceptualize the physical world.

Opponents claim there is no support for this interpretation. In fact, they claim functional viewpoints are equally as natural. Is there proof for the OOD claim? The answer is no. There is no empirical evidence to support the naturalness of the OOD view.

The second claim is that OOD objects somehow map more clearly to the physical world than do functional components in an entity relationship (ER) or data flow diagram (DFD). The claim is the transition from those conceptual models to a physical structure requires a significant and often difficult change of perspective.

The idea that object models are somehow closer to their physical counterparts than functional models is very convincing from an intuitive point of view. However, this claim is likewise completely unsubstantiated by empirical evidence. Each side has its supporters and each claim superiority for a variety of reasons.

What's worse is that the debate will likely continue indefinitely primarily because both interpretations are really just different views of the same thing, like the two sides of a coin.

From the OO point of view, it's certainly true that most systems (certainly all business systems) have a suite of identifiable objects that render specific services. However, from a functional point of view that same system certainly has a host of specific and identifiable functions as well. It's like viewing the system under development in multiple dimensions. This provides the developer a clear advantage when it comes to uncovering those illusive requirements.

Using hindsight, Object Oriented developers always point to the long track record of failures surrounding the functional approach. It's likely, however, that once OOD has been around a while, its track record will no doubt take on a similar look.

Unfortunately, the real kicker is developer bias. Most middle aged developers were weaned on functional decomposition while the new crowd is being raised on a mix of both. Maybe, down the road, we'll end up with a generation of developers who can effectively meld the two paradigms together.

The result of that symbiosis might be a totally new paradigm whose contribution to successful software development might yield perfect software requirements after all. When that point of perfection is reached, software development will truly fit the description of engineering discipline.

RR 2 Box 168, Jericho, VT 05465, 802-899-3115 Info@lavalleeccs.com