summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--parnas-a-rational-design-process.rst116
1 files changed, 30 insertions, 86 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst
index 0fa6a3b..d2ba84c 100644
--- a/parnas-a-rational-design-process.rst
+++ b/parnas-a-rational-design-process.rst
@@ -14,11 +14,9 @@
.. contents:: 内容目录
-通篇总结
+通篇总结 - 伍泰炜 OK
-------------------------------------------------------------------------
-伍泰炜 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
读完全文之后,我感觉作者能把前面十几页的内容写出那么多字,真是十分了不
起,可能这就是科研工作者的特长吧,把一个东西反复讲述,使得论文的篇幅变
@@ -58,12 +56,9 @@
-Page 1
+Page 1 - 徐梦旗 OK
------------------------------------------
-徐梦旗 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
理性设计过程: 如何、为何要仿制它
摘要
@@ -79,12 +74,9 @@ Page 1
-Page 2
+Page 2 - 田遍地 OK
----------------------------------------------------------
-田遍地 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
理性设计过程: 如何、为何要仿制它
**David L.Parnas** - 加拿大维多利亚大学计算机科学系,美国华盛顿海军研究实验室计算机科学和系统分支
@@ -108,12 +100,9 @@ I. 寻找哲人之石: 为什么要理性设计过程?
-Page 3
+Page 3 - 徐闰钞 OK
-----------------------------------------------
-徐闰钞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
(所有可以被归类为“自顶向下”的方法都是我们希望有一种合理又系统的软件设计方法的结果。)
本文既带来坏消息,也带来好消息。坏消息是,在我们看来,我们永远找不到哲
@@ -145,12 +134,9 @@ II. 为什么软件设计“过程”总是理想化?
-Page 4
+Page 4 - 吴贞娴 OK
-------------------------------------------------------------------
-吴贞娴 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
5. 用人就会有人为错误。无论我们的决策过程多么理性,无论我们的相关事实
收集和组织多么好,我们都将会犯错。
@@ -179,12 +165,9 @@ III . 尽管如此, 为什么描述理性理想化过程是有用的呢?
-Page 5
+Page 5 - 余慧 OK
---------------------------------------------------------------
-余慧 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
(与吴贞娴翻译的最后一段同: 上文所提及的内容,很明显为每个深思熟虑过
的人所知、为坦诚的人所承认。尽管如此,我们仍旧能看到以软件设计过程为主
题的会议、研究软件设计方法论的工作小组,以及为了丰厚市场利益扬言能描述
@@ -215,12 +198,9 @@ Page 5
-Page 6
+Page 6 - 魏含饴 OK
--------------------------------------------------------------------------
-魏含饴 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
5. 外部人员对项目进展定期审查对良好的管理不可或缺。 如果项目试图紧随
理想过程,审查就会更容易。
@@ -254,18 +234,17 @@ V. 理性设计过程是什么?
每一个工作产品的审查以及对生成的可执行代码的测试。
-Page 7
+Page 7 - 叶红霞 OK
---------------------------------------------------------------------
-叶红霞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
(在实施本文描述的过程时,我们对每一个工作产品进行了广泛而系统的审查,
并对生成的可执行代码进行了测试。)
-A. 建立并记录需求
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+A. 建立并记录需求
+````````````````````````````````````````````````````````````````````````````````
+
+
要成为理性的设计师, 为了成功,我们必须知道我们必须做什么。 我们将其
记录在称为需求文档的工作产品中。 在我们设计之前就完成此文档,这样我们
@@ -293,12 +272,9 @@ A. 建立并记录需求
- 在系统投入使用长时间后,需求文档可以用于为将来的需求变更定义约束条件。
-Page 8
+Page 8 - 王如韵 OK
--------------------------------------------------------------------------
-王如韵 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- 它可以解决争议; 我们不再需要成为应用程序专家或咨询应用程序专家。
因为通常没有组织良好的信息来源, 确定详细的需求很可能是这个过程中最困
@@ -324,13 +300,9 @@ Page 8
-Page 9
+Page 9 - 蒋佳玲 OK
---------------------------------------------------------------------
-蒋佳玲 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
我们通过把关注点分离( **Separation of Concerns** )到章节,来获得需求
文档的完整:
@@ -359,12 +331,9 @@ Page 9
-Page 10
+Page 10 - 应舸
----------------------------------------------------------------------------
-应舸
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
为了确保文档的统一性和完整性,文档编写的组织过程背后必须有一个简单的数学模型。
我们的模型是由我们在实时系统上的工作所激发的,但正因为如此,它具有完全一般性。
所有系统都是实时系统。
@@ -386,32 +355,27 @@ Page 10
.. _B:
B. 设计并记录模块结构
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
+````````````````````````````````````````````````````````````````````````````````
+
除非产品很小,小到能由单个程序员来做,否则我们必须想一想如何将工作分解为任务,即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责, 把我们的设计决策 (design decision) 封装在该模块。 模块里可以有子模块,也可以单独作为一个工作任务。
-Page 11
+Page 11 - 徐焕众 OK
-----------------------------------------------------------------------
-徐焕众 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
模块指南用来避免重复,避免空隙,实现 **关注点分离 (separation of concerns)** 。 最重要的, 当产品有问题时, 用来帮助维护人员找出对应的模块。 记录设计决策的文档与在维护阶段使用的文档是同一个文档。
如果我们努力地将信息隐藏 (information hiding) 或 关注点分离 (separation of concerns) 应用于大型系统,那么肯定会产生大量模块。 没有其他结构,只是简单列出模块名的指南,只对熟悉系统的人有帮助。 而我们的模块指南是树形结构的, 它将系统划分成几大模块,并以相同的方式细分每个模块,直到所有模块都非常小为止。 这种文档的例子, 参见[3]。 对这一办法及其好处的讨论,参见[15,6]。
C. 设计并记录模块接口
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+````````````````````````````````````````````````````````````````````````````````
高效快速的软件生产需要使程序员能独立工作。 模块指南定义了模块职责,但没有给出足够的信息使得每个人能去独立实现模块。 为此,每个模块必须指定精确的接口。 每个模块都必须有 **模块接口规范 (Module Interface Specification)** ; 规范必须正式,并提供每个模块的黑箱图片 (black box picture)。 规范由资深设计师撰写, 并由接口实现者与接口使用者一起评审。 一个模块的接口规范只需包含足够使其他模块的程序员使用该模块功能的信息, 而不需要其他信息。 接口实现者也需要 **模块接口规范** 。· 我们写的文件由两者使用。
-Page 12
+Page 12 - 何可人 OK
------------------------------------------------------------------------------
-( 何可人 OK )
-
虽然,每人负责写一个文件, 但这些文件实际上是在模块实现者、模块使用者, 对模块设计感兴趣的人(如审稿人)商议过程中产生的。 这些规范文件的主要内容有:
@@ -429,18 +393,16 @@ Page 12
D. 设计并记录模块内部结构
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+````````````````````````````````````````````````````````````````````````````````
一旦指定了模块接口, 实现可以作为独立任务去执行。 但是,开始编码之前, 我们想在模块设计文档中记录主要的设计决策。 这个文档允许我们编码前对设计有效的评审, 并向未来的维护程序员解释代码背后的意图。
在某些情况下, 模块只是被简单地分成几个子模块, 设计文件是另一个模块指南。 在这种情况下,该模块的设计过程在上面的步骤 B_ 处继续。
-Page 13
+Page 13 - 袁世家
-------------------------------------------------------------------------------
-( 袁世家 )
-
在另一些情况下,我们从描述内部数据结构开始;还有一些情况是,数据结构被子模块使用(和隐藏)。对于每一个访问函数,我们引用一种函数或者描述数据结构上的影响的LD关系。对于每一个模块所返回给使用者的数值,我们都提供了另一种数学函数,这个抽象函数将数据结构的值和其返回值一一对应。对于每一个不确定的事件,我们描述了怎样去检查它。最后,我们还提供了一种证明方法,这种使用此类性质来编程的观点可以满足模型的规格。
@@ -448,19 +410,17 @@ Page 13
如果我们不能编写一个可读的高级语言,例如,如果没有可用的编译器,我们使用伪代码作为文档的一部分。我们发现由另外某个人写伪代码而不是最终的程序员写代码,并且让两个程序员负责两种代码的连贯性是很有用的。
E. 设计并且记录使用层次结构
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+````````````````````````````````````````````````````````````````````````````````
一旦我们知道所有的模型和它们的许可程序,就可以设计使用的层次结构。他被方便地记录为二进制矩阵,当且仅当位置(a,b)的入口为真,程序A的正确性取决于系统中是否存在正确的程序B。使用层级结构定义了可以由删除整个程序并且没有重写任何程序获得的子集。这对于分阶段递交,故障弱化系统,和程序集合的发展很重要。
-Page 14
+Page 14 - 陈肖飞 OK
------------------------------------------------------------------------------
-陈肖飞 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
F. 编写程序
+````````````````````````````````````````````````````````````````````````````````
在设计和文档编制完成后,我们就可以编写代码了。我们发现这件事进展的迅速
而顺利。我们认为,代码注释不应该包含文档中已经有的内容。否则,系统维护
@@ -487,12 +447,9 @@ A. 当前的文档有什么问题? 为什么它不便使用? 为什么它
-Page 15
+Page 15 - 陈俊蕾 OK
----------------------------------------------------------------------------
-陈俊蕾 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
文档中多余的注解是没必要的,且会使系统维护变得更加昂贵。 除此之外,还
会增加代码与原文档不符的可能性。
@@ -517,12 +474,9 @@ VI. 文件在此过程中充当什么样的角色?
-Page 16
+Page 16 - 王海榕 OK
------------------------------------------------------------------------------
-王海榕 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
如何避免这些问题?
理想设计过程中, 文档既满足了开发人员需求, 也满足了维护人员的需求。上
@@ -551,12 +505,9 @@ execution)”, 我们花大力气来设计每个文件的结构。 通过声
-Page 17.a
+Page 17.a - 周佳威
--------------------------------------------------------------------------------
-周佳威
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
这样生成的文档既不简单也不轻松,但也不枯燥。我们利用表格、公式和形式符
号来增加信息的密度。我们的组织规则防止了信息重复,其结果是文档化,必须
非常认真地阅读,但回报读者详细和准确的信息。为了避免传统文档中出现混淆
@@ -580,13 +531,9 @@ Page 17.a
情发生的方式和事情的方式。
-Page 18
+Page 18 - 方梓安 OK
-----------------------------------------------------------------------------------
-方梓安 OK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
vii. 如何假装理想的过程?
上文描述了我们希望遵循的理想过程,以及这一过程所产生的文档。 我们通过
@@ -615,12 +562,9 @@ vii. 如何假装理想的过程?
-Page 20
+Page 20 - 刘莉莉
----------------------------------------------------------------------------------
-刘莉莉
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
从这个过程得到回报的例证是由我们几年前写的软件需求文档提供的,其作为理
想过程演示的一部分[9]。通常,人们认为需求文档在编码开始之前就生成了,
并且不会再使用它。然而,事实证明并非如此。那些满足我们的要求文件的软件,