One important feature of top-down design is that at each level the detail of the design at lower levels is hidden. Only the necessary data and control that must be passed back and forth over the interfaces are defined. Furthermore， if a data structure is contained wholly within a lower level module， it need not be specified until that level be reached in the design process. However， if several modules at some level must share data， then the data structure must be chosen before progressing to a lower level. The design will include both the data structure and the means of data access for each module involved.
The bottom-up design starts with analysis of specifications of the key parts， so the feasibility of the design is tested at the early stage. If the design is not feasible under the given specifications and constraints， the requirements are changed and the design proceeds without the danger of incompatible and unrealizable specifications undiscovered until late in the design process. But in bottom-up design， each module is coded as soon as its design is fixed， in contrast with the top-down process.
It is not uncommon to have mixture of top-down and bottom-up design and coding used in a project. It is a good idea to have a top-down design and bottom-up coding， and vice versa.
The structured programming philosophy aims to provide a well-defined， well-formulated and simple approach to program design. Structured programming requires the use of single-entry and single-exit control structures. The classical technique used to implement these principles is to restrict all control constructs to one of the three statements.
The advantages of structured programming are obvious：
（1） Clarity—structured programs generally have clarity and logical pattern to their control structure which is a tremendous advantage throughout the design process.
（2） Productivity—programmers who use structured techniques show a significant increase in instructions coded per man-hour of work. Similar advantages are claimed for the test phase.
（3） Fixed style—structured programming tends to limit the coding to a few straightforward design approaches. This aids the designer's associates and successors in understanding the design.
（4） Maintenance—the clarity and modularity of a structured design is of great help in localizing an error and redesigning the offending section of code.
（5）Redesign—most large software products are subject to occasional redesign （often called enhancement）. The clarity and modularity of structured design maximize the amount of code， which can be reused.
【Vocabulary】
top-down
自顶向下
bottom-up
由底向上
decomposition
n. 分解，腐烂
process
vt. 加工，处理
module
n. 模数，模块
straightforward
adj. 正直的，坦率的，简单的
hidden
adj. 隐藏的
furthermore
adv. 此外，而且
wholly
adv. 整个，统统，全部
specification
n. 详述，规格，说明书
coding
n. 译码
vice
n. 恶习，恶行，罪恶，缺点
philosophy
n. 哲学，哲学体系，冷静
clarity
n. 清楚，透明，明确性
maintenance
n. 维护，保持，可维护性
occasional
adj. 偶然的，临时的，非经常的
modularity
n. 模块性
structure programming
结构化程序设计
【参考译文】
现代软件设计的方法
下面简单论述一下诸如自顶向下程序设计、自底向上程序设计和结构化程序设计的现代软件设计中的一些主题。
自顶向下程序设计基本上是一个重点放在程序的控制流程和控制结构的分解过程。第一步是研究手中任务的各个部分，并将其分解为几个模块（一般是3到10个）。第二步是将模块进一步细分为独立的子模块，这个过程将不断重复直到分解的模块足够小，能够透彻地理解，并能很快地以直接和简单的方式编程。由此形成一个多层逻辑或控制结构，很明显某些模块将扩展到很多层。
自顶向下程序设计的一个重要特征是对每一层而言，其下面层次的详细设计被隐藏起来，只有需要回传及超出接口的必要数据和控制被定义。此外，如果一个数据结构完全属于一个低层模块，设计过程中在到达该层之前不需要对其进行说明。然而当同一层次中的几个模块要共享数据时，在向下一层前进之前就应对数据结构做出选择。设计将包括数据结构和各个模块中涉及访问数据的方法。
自底向上的程序设计从分析关键部分的技术要求开始，因此设计的可行性在早期就被测试。在给定的技术要求和约束条件下，如果设计不可行则需求就必须更改，程序设计也不必承担后期才发现与技术要求互相矛盾或不可实现的风险。但是与自顶向下程序设计过程相比，在自底向上的程序设计中，每个模块的设计一旦确定就可以开始编程了。
在一个项目中，把自顶向下的程序设计和自底向上的程序设计或编程结合在一起是很常见的，而且把自顶向下的程序设计和自底向上的编程结合在一起是一个很不错的方法，反之亦然。
结构化程序设计的指导思想是提供一种定义明确、表达清晰而且简单的程序设计方法。结构化程序设计要求使用单入口和单出口的控制结构，用于贯彻这一要求的经典方法是限制控制结构，只能在三种经典结构中选择一种。
结构化程序设计的优越性是明显的：
（1）明确性——结构化程序通常具有明确性，控制结构合乎逻辑，这在程序设计过程中是一个相当大的优势；
（2）生产效率——使用结构化技术的程序员每人在一小时编写的代码有相当大的增加，相似的优越性在测试阶段也有所体现；
（3）固定的风格——结构化程序设计倾向于把编程限制在一些直截了当的设计方法内，这有助于设计人员的同事或接任者理解他的设计；
（4）可维护性——明确性和模块化对于定位错误和重新设计有缺陷的部分非常有帮助；
（5）重新设计——大部分大型软件产品都会经历一到两次重新设计的过程（通常叫做增强）。
【Reading Material】
Classic Testing Mistakes
When testing， you must decide how to exercise the program， and then do it. The doing is ever so much more interesting than the deciding. A tester's itch to start breaking the program is as strong as a programmer's itch to start writing code -- and it has the same effect： design work is skimped， and quality suffers. Paying more attention to running tests than to designing them is a classic mistake. A tester who is not systematic， who does not spend time laying out the possibilities in advance， will overlook special cases. They may be the same subtle ones that the programmers overlooked.
Concentration on execution also results in un-reviewed test designs. Just like programmers， testers can benefit from a second pair of eyes. Reviews of test designs needn't be as elaborate as product design reviews， but a short check of the testing approach and the resulting tests can find significant omissions at low cost.
What is a test design？
A test design should contain a description of the setup， inputs given to the product， and a description of expected results. One common mistake is being too specific about test inputs and procedures.
Suppose you're testing a banking application. Here are two possible test designs：
Design 1
Setup： initialize the balance in account 12 with $100.
Procedure：
Start the program.
Type 12 in theAccount window.
Press OK.
Click on the 'Withdraw' toolbar button.
In the popup dialog， click on the “all'” button.
Press OK.
Expect to see a confirmation popup that says "You are about to withdraw all the money from this account. Continue？"
Press OK.
Expect to see a 0 balance in the account window.
