summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--parnas-a-rational-design-process.rst17
1 files changed, 10 insertions, 7 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 2261a75..a1f11e1 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -229,7 +229,7 @@ V. 理性设计过程是什么?
A. 建立并记录需求
-````````````````````````````````````````````````````````````````````````````````
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -309,8 +309,9 @@ A. 建立并记录需求
.. _B:
B. 设计并记录模块结构
-````````````````````````````````````````````````````````````````````````````````
-
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
除非产品很小,小到能由单个程序员来做,否则我们必须考虑如何将工作分解为几个工作任务,即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责, 把我们的设计决策 (design decisions) 封装在各模块。 一个模块可以由多个子模块组成,也可以被视为单个工作任务。
@@ -322,7 +323,7 @@ B. 设计并记录模块结构
如果我们勤勉地将信息隐藏 (information hiding) 或关注点分离 (separation of concerns) 应用于大型系统,那么最终肯定会有大量模块。只是简单列出模块名而没有其它结构的指南,只会对熟悉系统的人有帮助。 我们的模块指南有一个树形结构,它将系统划分成少量几个模块,并以相同的方式细分每个模块,直到所有模块都非常小为止。 这种文档的完整例子, 见[3]。 对这一办法以及其好处的讨论,见[15,6]。
C. 设计并记录模块接口
-````````````````````````````````````````````````````````````````````````````````
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
高效快速的软件生产需要程序员能够独立工作。模块指南定义了模块职责,但没有给出足够的信息去允许独立实现模块。每个模块必须规定精确的接口。为每个模块写一个 **模块接口规范 (Module Interface Specification)** ;规范必须正式,并提供每个模块的黑箱图片。规范由资深设计师撰写,并由潜在的接口实现者与会用到这些接口的程序员一起评审。 一个模块的接口规范只需包含足够信息使其他模块的程序员能够用该模块的功能即可,而不需要其他信息。 这也是模块实现者需要的信息。我们产生的文档被两者(其他模块的程序员、本模块实现者)使用。
@@ -348,7 +349,7 @@ C. 设计并记录模块接口
D. 设计并记录模块内部结构
-````````````````````````````````````````````````````````````````````````````````
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
一旦指定了模块接口, 除了评审外,它的实现可以作为独立任务去执行。 但是,开始编码之前, 我们想在模块设计文档中记录主要的设计决策。 该文档允许编码前对设计的高效评审, 并向未来的维护程序员解释代码背后的意图。
@@ -365,7 +366,8 @@ D. 设计并记录模块内部结构
如果我们无法用易读的高级语言编程,例如,如果没有编译器可用,我们就把伪代码作为文档的一部分。我们发现让最终编码者以外的人来写伪代码,并让两个程序员负责保持程序的这两个版本一致是有用的 [7]。
E. 设计并且记录使用层次 (uses hierarchy)
-````````````````````````````````````````````````````````````````````````````````
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
一旦我们知道所有的模块与它们的访问程序,就能设计使用层次 [13] 了。使用层次可以用一个二进制矩阵方便表示,当且仅当程序A的正确性依赖于系统中存在正确的程序B时,位置(A,B)上的条目为真。**使用层次** 定义了子集组成的集合, 这个集合可以通过删除整个程序而无需重写任何程序得到。使用层次对于分阶段交付,故障弱化(fail-soft)系统,与程序族开发是重要的 [12]。
@@ -376,7 +378,8 @@ E. 设计并且记录使用层次 (uses hierarchy)
F. 编写程序
-````````````````````````````````````````````````````````````````````````````````
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
完成所有这些设计和文档之后,我们就已经准备好编写实际的可执行代码了。我们发现编写过程快速而流畅。我们认为,代码注释不应该包含文档中已经写有的冗余内容。这是不必要的,这会使维护系统更加昂贵,同时增加了代码与文档不一致的可能性。
(因为会出现代码注释改了,而忘了更新对应位置的文档。或者文档改了,而忘了更新对应位置的代码注释。-- 译者注)