1 Page of 5
Design issues for Large Applications
Software development is an iterative and incremental process. Each stage of the process is revisited repeatedly during the development, and each visit refines the end products of that stage. In general, the process has no beginning and no end. When designing and implementing a system, you start from a base of other peoples designs, libraries, and application software. When you finish, you leave a body of design and code for others to refine, revise, extend and port. Naturally, a specific project can have a definite befinning and end, and it is important to delimit the project cleanly and precisely in time and scope. However, pretending that you are starting from a clean slate can cause serious problems. Pretending that the world ends at the final delivery can cause equally serious problems for your successors. One implication of this is that design is almost always redesign based on a previous design and some implementation experience. Furthermore, the design is constrained by schedules, the skills of the people involved, compatibility issues, etc. a major challenge to a designer/manager/programmer is to create order in this process without stifling innovation and destroying the feedback loops that are necessary for successful development. The development process has three stages: - analysis: defining the scope of the problem to be solved - design: creating an overall structure for a system - implementation: writing and testing the code Please remember the iterative nature of this process it is significant that these stages are not numbered. Note that some major aspects of program development dont appear as separate stages because they ought to permeate the process: - experimentation - testing - analysis of the design and the implementation - documentation - management Software maintenance is simply more iterations through this development process. For small-to-medium projects, there is often no distinction made between analysis and design; these two phases have been merged into one. Similarly, in small projects there often is no distinction made between design and programming. The development cycle Developing a system should be an iterative activity. The main loop consists of repeated trips through this sequence: 1. Examine the problem. 2. Create an overall design. 3. Find standard components.
Page 2 of 5 - Customize the components for this design. 4. Create new standard components. - Customize the components for this design. 5. Assemble the design. Design aims The implication is that the system must be designed to remain as simple as possible under a sequence of changes. We must design for change; i.e. we must aim for - Flexibility - Extensibility, and - Portability This is best done by trying to encapsulate the areas of a system that are likely to change and by providing non-intrusive ways for a later designer/programmer to modify the behavior of the code. This is done by identifying the key concepts of an application and giving each class the exclusive responsibility for ht maintenance of all information relating to a single concept. In that case, a change can be effected by a modification of that class only. Ideally, a change to a single concept can be done by deriving a new class or by passing a different argument to a template. Naturally, this ideal is much easier to state than to follow. Design steps Consider designing a single class. Typically, this is not a good idea. A class does not exist in isolation but is defined together with logically related classes. Typically, one works on a set of related classes. Such a set is often called a class library or a component. Sometimes all classes in a component constitute a single class hierarchy, sometimes they are members of a single namespace. Here is a series of steps that might be followed in designing a component: 1. find the concepts/classes and their most fundamental relationships 2. refine the classes by specifying the sets of operations on them. 3. refine the classes by specifying their dependencies. 4. specify the interfaces. Typically several loops through this sequence are needed to produce a design one can comfortably use for an initial implementation or a re-implementation.
Page 3 of 5
Good advice for every Software Designer
Keep It Small and Simple - Dont solve problems that dont yet exist. - Solve the specific problem, not the general case but dont make needlessly it inflexible either - Keep the door open for extension through composition and inheritance - Use polymorphism to encapsulate need to know in specific derived classes, allowing clients to be blissfully ignorant, knowing only the base class protocol. - Design function code so that it: fits on a single page Decompose into smaller tasks - Break a complex operation into smaller simpler pieces. - if you cant say it well in English (Spanish, Bengali, Mandarin, ) you cant say well it in C++ - The act of writing out a description of what a program does, and what each component does, is a critical step in the thinking process, even if the result is just one or two pages. - If you cant write it clearly then you probably havent fully thought out either the problem or its solution. - When youre done, you have a specification - the only reasonable basis for testing. - Design is a decomposition process in the application domain. - Implementation is a re-composition process in the solution domain. Read code Read a lot of code. You learn by seeing how others write code. Look at as many samples of good code as you can. Look critically at your own code. Read several of the better trade journals, e.g., C++ report, C/C++ Users Journal, IEEE Computer Magazine, IEEE Software Magazine. Write a lot of code. When youre starting a big job, write small prototypes to try out your ideas and be prepared to throw them away or rebuild them before launching the final construction. Use an editors red pencil on your code. Strike out unnecessary code, simplify, reword, repartition, until youre reasonably satisfied. Be prepared to throw the first one away. Formatting and documentation Software should be self-describing: Unlike most other engineering disciplines, software has the ability, if well written, to capture, store, and disclose on demand, the technology used for its construction.
Page 4 of 5 if you use specialized algorithms or technology place citations to references so others can understand how your code works. Uncommented code has no value: uncommented code is unmaintainable Every function should have a (brief) prologue - perhaps only a single line and comments to describe any subtle code.
Comments Dont comment the obvious. Do put comments where they are needed: Once per file: provide prologue: state name of file, brief phrase describing contents, state language, platform, application, and author Once per function: state action discuss inputs and outputs only if type and format are not obvious put brief comments in code only if semantics are not obvious Diagrams Use diagrams in architecture concept documents: class...