Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpda!hpdslab!hpiacla!scottg From: scottg@hpiacla.HP.COM (Scott Gulland) Newsgroups: comp.software-eng Subject: Re: Writing code by hand (was: Basics of Program Design) Message-ID: <580001@hpiacla.HP.COM> Date: 5 Jul 88 18:21:03 GMT References: <900@td2cad.intel.com> Organization: Hewlett Packard Lines: 98 > 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] * **************************************************************************