Re: Rational Edge Design Papers

[Al Christians <alc@PublicPropertySoftware.com>]

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? 

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?

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. 

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


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