Re: Large System Decomposition

Re: Large System Decomposition

[sun-barr!cronkite.Central.Sun.COM!jethro!exodus!oogoody.Eng.Sun.COM!tmh]

>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.

Re: Large System Decomposition

[24122-Haim Kilov(L028)m000]

"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."

--Don't forget, however, about relationships between managed objects that,
quoting the new draft of ISO standard, are "significant entities, warranting
conceptual attention". This draft attempts to provide formal specification
tools for relationships -- we have done it already for generic relationships
of different meta-types here in Bellcore. These specifications are
formulated using behavioral properties of an entity (call it "managed object")
and its associated entities. The same approach is recommended by the recently
accepted ANSI OODBTG Object Data Management reference Model.

As I had mentioned some time ago, Bellcore Special Report "Information modeling
concepts and guidelines" discusses some of these issues at some length.
Some other papers/documents will be published.

Hope this helps.

Haim Kilov
haim@bcr.cc.bellcore.com

Re: Large System Decomposition

[Operator]

In article <1991Sep10.220036.20777@porthos.cc.bellcore.com> haim@taichi.UUCP (2
4122-Haim Kilov) writes:
>--Don't forget, however, about relationships between managed objects that,
>quoting the new draft of ISO standard, are "significant entities, warranting
>conceptual attention". This draft attempts to provide formal specification

Yes, this is one of the most interesting and novel aspects to me, taking 
relationships whose bits and pieces are generally scattered about in code and 
making them a formal thing in and of themselves. 

Could you elaborate a little on what you've done? It may be useful to
consider some concrete examples...

>As I had mentioned some time ago, Bellcore Special Report "Information modelin
g
>concepts and guidelines" discusses some of these issues at some length.

How do I go about getting the special report? Sounds interesting.