Re: Rational Edge Design Papers

["Marc A. Criley" <mcquad3@earthlink.net>]

Al Christians wrote:
> 
> Marc,
> 
> Thanks very much.
> 
> Is it right that in the style of architecture (morphology?) used in
> your system,  the Data Flow Managers could be as large and complex
> (you only had two, you say) as needed, and that's not a problem?

A driving goal of the architecture was to make the Data Flow Managers
(tasks) _not_ be large and complex.  The "transformation servers", i.e.,
algorithms, were where the bulk of the processing was done.  The tasks
orchestrated the data flow through the system.  That is, data arrived
via an I/O server, the Data Flow Manager determined what kind of data it
was, and then invoked the appropriate transformation.  Each
planning-data entity had its two dedicated flow managers, which dealt
solely with managing the processing for that Tomahawk engagement.

These transformations were typically quick, so the task blocked while
the processing was being done.  Some, though, required significantly
more time (routing a Tomahawk around sea-borne friends and foes,
islands, etc. could be complex).  In those cases, the primary Data Flow
Manager interacted with a subordinate one, which then drove the
appropriate processing, and the primary manager went back to waiting for
input.

(Note that ATWCS EPC does not perfectly conform to Buhrer's concept, but
it turns out his concepts provide a useful framework with which to
describe the architecture of that subsystem.)

> 
> The paper says "Any structured programming language is suitable for
> implementing a data flow manager."  Does that mean also structured
> design with hierarchical decomposition?  If I do that, then I would
> summarize the paper as recommending:
> 
> 1. use structured design.
> 
> 2. Whenever you see a transformation, I/O, or encapsulatable data
> entity, split that out into a separate design element.
> 
> Am I missing something here?

That appears to be what he is saying.  Partition the functionality into
those design entities, then tie them together with Data Flow Managers.

> 
> This is structured-on-top O-O on bottom programming, right?  The O-O
> evangelists would not like that, I think, since O-O systems are not
> supposed to have a top.

I think that's not a bad way to characterize Buhrer's approach.

A problem with OO sometimes cited by its critics is that it results in
an explosion of objects, and doesn't address well how all these objects
are supposed to be coordinated, i.e., there's "no top".

A few years ago Link Flight Simulation (a company not known for software
innovation) in Binghamton, NY, tackled this very issue when they started
the move towards OOD.  They came up with an approach (and I'm not saying
they were the first to come up with it, but I have seen it reinvented a
couple times since then) where you developed your classes and objects,
and then created a top-level data/control flow diagram to tie all the
objects together.

(The notation they used for this top-level flow diagram was devised and
published by William Bennett, with the notation subsequently being known
within the company as "Bennett Notation".  There's a handful of us
ex-Linkers around the industry who know and continue to swear by that
notation as the neatest thing since sliced bread :-)

This approach neatly addressed the OO coordination problem, and since
Buhrer is about the third incarnation of it that I've now seen, there
must be something to it!

> 
> Keeping this on-topic for CLA, can anyone offer gratuitous explanations
> of what Ada features best support this morphology?

Data Entity : records and/or tagged types, embedded in packages
I/O servers : procedural constructs...data comes in, data goes out...
Transformers: procedural constructs...Inputs -> magic -> Outputs
Flow Manager: tasks if multiple flows ought to be occurring
               simultaneously, otherwise a plain loop would
               likely suffice: wait..process..wait..process...etc.

Marc


> 
> Al
> 
> "Marc A. Criley" wrote:
> >
> > Al Christians wrote:
> > >
> > > See:
> > >
> > > http://www.therationaledge.com/content/jan_01/f_craftsci_kb.html
> > >
> > > I've read this paper without getting a real good idea how one would
> > > follow the method to construct larger progams out of the simple
> > > components described.
> > >
> >
> > As I read the article I observed that its suggested approach fit well
> > with the software architecture of a project I previously worked on for
> > several years.
> >
> > That project was the rearchitected Engagement Planning and Control (EPC)
> > subsystem of the Advanced Tomahawk Weapon Control System (ATWCS).
> > (ATWCS is not the Tomahawk flight software, it's the on-ship launch
> > planning facility.)
> >
> > In the article Buhrer identifies four types of design elements.  I won't
> > repeat his description (see the article), but I will describe how they
> > fit with the EPC software architecture.
> >
> > o Data Entity - Each of the different types of ATWCS planning data were
> > tightly encapsulated into highly cohesive data collections, usually
> > implemented as Ada records.  Within the system there was always a
> > "master" instance of each particular data type that was always
> > considered Truth.
> >
> > o I/O Server (external interface) - EPC interacted with externals in two
> > ways:  First, with peer subsystems (such as the launch hardware
> > controller) the interaction was via a formally controlled API, with
> > dedicated software monitoring the APIs and through which all external
> > communication was funneled--both incoming and outgoing.  Second, for
> > subordinate subsystems, such as the operator's GUI interface,
> > interaction simply occurred through sockets, but again, with dedicated
> > software controlling all traffic passing through those sockets.  The
> > idea was to have single points of control for all external interfaces,
> > to simpify the architecture and design, ensure a consistent approach to
> > external interfaces, and to aid debugging.
> >
> > o Transformation server - These were the straighforward internal state
> > managers, route planners, etc. that provided the planning functionality.
> >
> > o Data Flow Manager - A pair of Ada tasks provided this functionality.
> > One of the tasks managed all updates to planning data based on the
> > information coming in to the system, initiated "transformations", and
> > saw to it their outputs were passed on.  The other task drove the
> > planning timeline, initiating activities at the scheduled times.  One
> > aspect Buhrer notes is that a Data Flow Manager's "activity" may
> > sometimes be "waiting for input".  The EPC software architecture was
> > designed such that its tasks spent the vast majority of their time
> > blocked while waiting for input.  The net result of this was that the
> > system was quiescent most of the time, consuming only a few percentage
> > points of CPU, despite the existence of _literally_ hundreds of
> > simultaneously active tasks.
> >
> > Marc A. Criley
> > Senior Staff Engineer
> > Quadrus Corporation
> > www.quadruscorp.com