From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=3.0 tests=BAYES_20,LOTS_OF_MONEY
	autolearn=ham autolearn_force=no version=3.4.5-pre1
Date: 10 Sep 91 19:52:56 GMT
From: sun-barr!cronkite.Central.Sun.COM!jethro!exodus!oogoody.Eng.Sun.COM!tmh@l
ll-winken.llnl.gov  (Todd Hoff)
Subject: Re: Large System Decomposition
Message-ID: <19790@exodus.Eng.Sun.COM>
List-Id: <comp.lang.ada>

>oriented nirvana (<-Where Pat Sajak stands).  The problem is that
>these problems seem somewhat academic and relatively inappropriate
>for "real-world" LARGE applications (Please, no arguments like: "Oh 
>yeah? DEFINE "real-world"!).  

The problem is you're trying to map an already decomposed
project onto OOD, which can be done, but is very difficult
and may not work at all without a complete restructuring
of your project.

OOD works wonderfuly in the large because object abstractions
work on other abstractions with no coupling at all other
than request and response messages.

Think of your project interms of what OSI calls Managed Objects,
which are resource encapsulations hiding behind a message based
interopable interface. Don't think in terms of subsytems or
function calls, it won't work. Think of the higher levels
of your system as active objects, modeled by processes or tasks
which must talk to each other through a well defined message
protocol, over a communication link. Don't think client server
or agent architecture unless it fits the needs of your Managed Objects.

The message protocol may just be an agreed upon sequence of
structures being passed around. The message channel could
be a message transfer within the same process, on the same machine,
withing the same network, or anywhere else, it shouldn't matter.
The routing layer of your system can efficiently 
transfer the message where it should go, worrying about
serialization and packetization.

Basing your design around Managed Objects also helps plan the
project as it's easy to assign implementation of a Managed
Object to a given programmer. Programmer's can develop
without coordination with other programmers, creating test
objects to exercise the Managed Objects they are tasked with,
and then when integration rolls around it will all fit together.
It works. It work on a 50+ million dollar project I was involved
with (in C++ BTW).

IMHO, OOP is not so much wasted as overemphasized on low level 
things like Lists, but that is always what we read about. 
OO{P,D,A} makes programming in the large not only managble but fun.

I also think proposals from the Object Management Group 
adopt something similar to OSI's Managed Objects.