From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cf8a34cc14497c2c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-19 06:25:42 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3A68404A.4B3BF902@earthlink.net> From: "Marc A. Criley" Organization: Quadrus Corporation X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Rational Edge Design Papers References: <3A664BF3.2FCB8C17@PublicPropertySoftware.com> <3A672744.2E7651C3@earthlink.net> <3A674222.8895E25F@PublicPropertySoftware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 19 Jan 2001 14:25:42 GMT NNTP-Posting-Host: 158.252.122.228 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 979914342 158.252.122.228 (Fri, 19 Jan 2001 06:25:42 PST) NNTP-Posting-Date: Fri, 19 Jan 2001 06:25:42 PST Xref: supernews.google.com comp.lang.ada:4211 Date: 2001-01-19T14:25:42+00:00 List-Id: 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