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 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 11 Dec 92 17:03:34 GMT From: prism!jm59@gatech.edu (MILLS,JOHN M.) Subject: Re: Ada & PDL (ick !) Message-ID: <78105@hydra.gatech.EDU> List-Id: In article eachus@oddjob.mitre.org (Rob ert I. Eachus) writes: > >In article <1992Dec10.154343.24720@mksol.dseg.ti.com> strohm@mksol.dseg.ti.com (john r strohm) writes: > >> Which raises my old favorite question: As I understand it, the >> output of the CODING phase of the project is compilable code, while >> the input to the coding phase is the design of the (insert >> buzzphrase of your choice here) to be coded. I normally _try_ to divide into: design, code, debug, integrate, [losts more debug], test, vacation. I know it's not that simple, but design concentrates on data and _what_ processing takes place between modules, routines, tasks, ..., _not_ on the processing implementation. Data structures, for example, should be designed as early as possible, and should specify 'internal interfaces' of the code. If I don't always realize my original design, I at least start with _some_ design, so I know "how much is enough" for each major project activity. YMMV. >> Now we have PDL that is compilable and compiled and is the same lanugage as >> the final implementation language for the project. Contractually, we are often required to submit our design to outside review, and this should be done before much effort is expended on coding. (I would try "proof of concept" code samples, try to confirm whether my timing targets are attainable, etc, with some compiled code, naturally.) I have also been required to submit my designs to internal review, along with H/W designs for modulators, transmitters, antennas, and so forth. Sometimes this has avoided big problems later in the project. (Sometimes not.) If you write code which only reflects the design (not the processing) of the software, I think you are mainly designing your data structures. This seems [somewhat] useful. If you know enough to proceed directly to code, fine. I guess this depends on the scope of the project. I have been offered PDL processing tools which expect specific types of descriptive header information, and turn it into structural and data-flow diagrams. I don't know if these tools are any good. We had gotten our code almost done, so we elected to produce the [contractually required] design description from the headers and comments already in our code. I won't argue this was ideal; only that each tool has an appropriate time of application. If you use it at the wrong time, it won't be as useful as at the right time. >> What I want to know is this: How SPECIFICALLY does this differ from just >> jumping straight into the coding? I hope I gave an answer to that. >> I really wonder about this: I don't know >> how to be certain in such a case that a real formal DESIGN was done, and >> failure to do the DESIGN properly has killed or maimed a lot of projects. I think it becomes essential when multiple programmers, or joint hardware and software tasks must be coordinated. I don't have any war stories but my own, and since I generally design first, they are all glorious victories. [;->) What experience have others had with CASE tools that proceed from specific type of design descriptions? Have they helped? hindered? Thanks. --jmm-- -- John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59 Internet: jm59@prism.gatech.edu ... Not so fast -- I'm still thinking.