scottg@hpiacla.HP.COM (Scott Gulland) (07/06/88)
> For the past few years my professors have rambled on about data > structures, compiler design and more, ad nauseam. But none of them > have ever mentioned the best way, (or any way really) to go about > sitting down and actually writing a program. ... etc. This is one area in which our educational institutions are very weak. Most of the projects I have worked on have had between five and forty engineers working on them and take one to two years to complete. The first step in all of these has been to develop the functional requirements and produce a psuedo user manual. This precisely defines the desired results of the product and helps to drive the latter test phases. At the completion of this step, the team begins to consider the design of the product. The types of projects I work on involve real time applications for the factory floor environment. These applications always contain multiple programs (processes) which need to operate in a semi-synchronous fashion (some processes are synchronized, some aren't), but are typically driven by asynchronous events. Note that other kinds of applications may require entirely different approaches to design. Now that you have a good idea on the types of projects I work on, here is how I approach design. As the design of the functional requirements comes to an end, I begin to work on how to design the problem in my head. I examine various approaches to the problem spending a week or two just thinking about how each might be implemented. This is essentially a brain-storming exercise. By the time the functional requirements are complete, I usually have isolated in my mind the best and most promising design approaches to the problem at hand. This technique involves considering any idea, no matter how bizzare, without prejudging its suitability as a solution. Each idea or approach is mentally evaluated with respect to design tradeoffs (eg. benifits vs detrements). Over time and much thought, some of these ideas begin to float to the surface as being most appropriate for the problem being worked on. I would like to make a couple of comments about this technique for the benifit of new engineers. Effective use of the technique requires extensive knowledge of the design tradeoffs for an operating system/ architecture as they apply to a specific class of applications. This in turn requires considerable development experience before you will know to make these tradeoffs. Therefore, I would not recommend that new engineers attempt to use this technique on complex projects. We then begin the formal part of design. On a small project the entire team participates while on a large project the top four or five technical engineers are chosen to formulate a high-level architecture. The design of the architecture involves breaking the problem into major modules and identifying the data flows between the modules. Note that the data flows usually do not contain a great amount of detail but are defined at the conceptual level. Following the initial draft of the high-level design, we begin to define in detail actual critical data items flowing between modules. We also break each module into its component subfunctions and some of the major data elements used within the module. Note that throughout this whole process we evaluate design tradeoffs and brainstorm different approaches. After several iterations of the above we arrive at a fairly solid high-level architecture for the problem. Following the high-level design, we perform schedule estimates for each module and submodule. Based on these schedule estimates we split up and distribute the components of the architecture to the entire team for detailed design work. Each member of the team is responsible for coming up with a detailed design for their assigned areas. Note that in large projects this may invovle further sub-teams. In any event, the team must possess excellent communication skills amongst themselves to insure that all modules integrate cleanly together. As I begin detailed design of my individual modules, I will go through the same mental brainstorming technique outline above only in much finer detail. After choosing the basic approach to apply to each module, I define the data structures being passed into and out of the module. I also attempt to define as completely as possible the major global data structures used within the module. At this point, if the module is fairly complex, I will use a variety of techniques to simplify it. Many times this will be psuedo-code. The team will then hold a series of design reviews for each of the individual modules. The design reviews usually catch most of the design defects and greatly aid the integration of modules once they are coded. We are also currently look at some of the new structured design tools comming out, such as IDE and Teamwork. However, it is still too early to tell how effective these are in aiding the design process. As we finish coding each module, we attempt to perform unit testing to what ever extent is possible. In large modules we will frequently unit test each function within the module as we complete it. Note that unit testing attempts to find defects in the functionality of the module as defined during design. ************************************************************************** * Scott Gulland | {ucbvax,hplabs}!hpda!hpiacla!scottg [UUCP] * * Indus. Appl. Center (IAC) | scottg@hpiacla [SMTP] * * Hewlett-Packard Co. | (408) 746-5498 [AT&T] * * 1266 Kifer Road | 1-746-5498 [HP-TELNET] * * Sunnyvale, CA 94086 USA | "What If..." [HP-TELEPATHY] * **************************************************************************
psc@lznv.ATT.COM (Paul S. R. Chisholm) (07/06/88)
< "Would you buy a used operating system from these guys?" > In article <1335@hp-sdd.HP.COM>, nick@hp-sdd.HP.COM (Nick Flor) writes: > It's infinitely easier to type 'dd' to erase a line in VI, than to > use a pencil eraser. >Nick V. Flor ..hplabs!hp-sdd!nick Exactly why I *don't* use vi in the design stage! I've got a terrible memory. Managing complexity is something I've got to be very conscientious about. My first hack at a top-down design is usually nowhere near right. With an editor, I'd just change the lines. On paper, I either cross out a couple of lines, or just start on a fresh page. (Bound notebooks are useful, because I don't misplace the old design.) This way, when I'm a third of the way through, I can very easily pick up the good parts of the previous design attempt. SCCS and such don't help in this phase. I hate logging a mistake in the source database. An operating system that stores the last n versions of a file can help, sort of. You often find that the old stuff you wanted was in n+1 versions ago. This fear discourages you from saving your work often, which can have other bad effects. And designing on paper has one great advantage: I can write about other stuff in the margins. -Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc AT&T Mail !psrchisholm, Internet psc@lznv.att.com I'm not speaking for my employer, I'm just speaking my mind.
lishka@uwslh.UUCP (07/07/88)
In article <1398@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: >< "Would you buy a used operating system from these guys?" > > >Exactly why I *don't* use vi in the design stage! I've got a terrible >memory. Managing complexity is something I've got to be very >conscientious about. My first hack at a top-down design is usually >nowhere near right. With an editor, I'd just change the lines. On >paper, I either cross out a couple of lines, or just start on a fresh >page. (Bound notebooks are useful, because I don't misplace the old >design.) This way, when I'm a third of the way through, I can very >easily pick up the good parts of the previous design attempt. Not to pick on VI, but this is why I use gnu-emacs. It has "infinite" undo. If you make a *big* mistake you can undo to your heart's content. I have done quite a few times. Also, gnu-emacs has different buffers, so if I need to save a piece of the file I am editting, I just yank out the code to be changed and safe in a spare buffer for the time being. Same with backup files...keep a backup of previous code that you might need to revert to. >SCCS and such don't help in this phase. I hate logging a mistake in >the source database. An operating system that stores the last n >versions of a file can help, sort of. You often find that the old >stuff you wanted was in n+1 versions ago. This fear discourages you >from saving your work often, which can have other bad effects. I am not sure about SCCS (I have never used it), but RCS has a tree-like structure for revisions. Mr. Tichy wrote a good article on it, which describes the system better than the documentation available; I can get the reference if you are interested. >And designing on paper has one great advantage: I can write about >other stuff in the margins. So true. Now that would be a *really* good innovation for computers...margins to write things in (in editors). Maybe I'll hack up gnu-emacs to do this ;-) >-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc >AT&T Mail !psrchisholm, Internet psc@lznv.att.com >I'm not speaking for my employer, I'm just speaking my mind. -- Christopher Lishka | lishka@uwslh.uucp Wisconsin State Lab of Hygiene | lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 | ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
mrd@sun.soe.clarkson.edu (Mike DeCorte) (07/08/88)
You often find that the old stuff you wanted was in n+1 versions ago. This fear discourages you from saving your work often, which can have other bad effects. In gnu emacs, there are the following variable that *you* can set. make-backup-files (nil or non-nill) kept-old-versions (a number, default 2) kept-new-versions (a number, default 2) Using this you can choose n. If you like you could make n=# of files you can put on our disk. I wouldn't advise it, but you could. :-) -- Michael DeCorte // (315)268-2292 // P.O. Box 652, Potsdam, NY 13676 Internet mrd@sun.soe.clarkson.edu // Bitnet mrd@clutx.bitnet
del@elric.UUCP (Delmont R. Fredericks) (07/10/88)
In article <1398@lznv.ATT.COM>, psc@lznv.ATT.COM (Paul S. R. Chisholm) writes: > > In article <1335@hp-sdd.HP.COM>, nick@hp-sdd.HP.COM (Nick Flor) writes: > > It's infinitely easier to type 'dd' to erase a line in VI, than to > > use a pencil eraser. : > > .... My first hack at a top-down design is usually > nowhere near right. With an editor, I'd just change the lines. On > paper, I either cross out a couple of lines, or just start on a fresh > page. (Bound notebooks are useful, because I don't misplace the old > design.) This way, when I'm a third of the way through, I can very > easily pick up the good parts of the previous design attempt. > : > And designing on paper has one great advantage: I can write about > other stuff in the margins. I would have to agree with Nick. Not only is it easily modifiable, but when you want scrutiny from several people on your design you can send several copies to a printer. I find that the biggest advantage is that once my design is final, whala its already in the system, no need to sit down and enter the final design in. However, I do identify some with Paul and my solution to keeping old designs is to use the printer. At least it gives the device some sense of purpose ;-). One can just as easily save and bind listings as they can other paper mediums and besides I find that listings on 130 column wide paper gives my infinitely more margin space for comments that notebook paper does. I feel that there really is no right or wrong way for recording ones design efforts. It all boils down to what you feel comfortable with. This does not mean that I am not open to suggestions for improvements, just that what works for you may not work entirely for me. I may like a portion of your method and work that into mine. Remember, one mans posion is anothers delight :-). -- Delmont R. Fredricks Jr. UUCP: ihnp4!clyde!herman!elric!phaze!del Unisys Computer Systems Div. meccts!herman!elric!phaze!del POB. 64525 MS. CD1B20 EMAIL: del@herman.STP.UNISYS.COM St. Paul, Mn 55164-0525 AT&T: (612)681-6965