diff options
| -rw-r--r-- | parnas-a-rational-design-process.rst | 73 |
1 files changed, 32 insertions, 41 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst index e30948e..2261a75 100644 --- a/parnas-a-rational-design-process.rst +++ b/parnas-a-rational-design-process.rst @@ -87,8 +87,7 @@ -Page 2 ----------------------------------------------------------- +(Page 2) I. 寻找魔法石： 我们为什么想要理性设计过程？ @@ -108,9 +107,7 @@ I. 寻找魔法石： 我们为什么想要理性设计过程？ -Page 3 ------------------------------------------------ - +(Page 3) 本文同时带来了好消息和坏消息。坏消息是，在我们看来，我们将永远找不到魔法石。 我们将永远找不到能让我们以完美地理性方式去设计软件的过程。好消息是我们 @@ -139,8 +136,7 @@ II. 为什么软件设计“过程”总是理想化？ -Page 4 -------------------------------------------------------------------- +(Page 4) 5. 除非不用人，否则无法避免人为错误（Human Errors）。无论我们的决策过程多么理性，无论我们对相关事实 @@ -167,8 +163,8 @@ III . 尽管如此， 为什么描述理性的理想化过程有用呢? 我们上文讲的东西甚为明显，为每个细心的思考者所知，为坦诚的人们所承认。尽管如此，我们还是看到以软件设计过程为主题的会议，关于软件设计方法论的工作组以及一个获利丰厚的、声称用描述逻辑的方法来设计软件的课程市场。这些人想要达到什么目的呢？ -Page 5 ---------------------------------------------------------------- +(Page 5) + .. （与吴贞娴翻译的最后一段同： 上文所提及的内容，很明显为每个深思熟虑过 @@ -191,8 +187,7 @@ Page 5 -Page 6 --------------------------------------------------------------------------- +(Page 6) 5． 外部人员对项目进展定期审查对良好的管理是必不可少的。 如果项目正试图遵循理想过程，审查将会更容易。 @@ -226,8 +221,7 @@ V． 理性设计过程是什么？ 以及对生成的可执行代码的测试。 -Page 7 ---------------------------------------------------------------------- +(Page 7) （在实施本文描述的过程时，我们对每一个工作产品进行了广泛而系统的审查， @@ -260,8 +254,8 @@ A. 建立并记录需求 - 在系统长时间投入使用后，需求文档可以用于为将来的变更定义约束条件。 -Page 8 --------------------------------------------------------------------------- +(Page 8) + - 它可以用于平息争论; 我们不再需要成为或咨询应用专家。 @@ -281,8 +275,8 @@ Page 8 -Page 9 ---------------------------------------------------------------------- +(Page 9) + 通过使用关注点分离（ **Separation of Concerns** ）获得以下部分，我们达到需求文档的完整性: @@ -305,8 +299,8 @@ Page 9 -Page 10 ----------------------------------------------------------------------------- +(Page 10) + 为确保文档的一致性与完整性， 文档组织结构背后必须有一个简单的数学模型。 我们的模型是由我们在实时系统上的工作所启发的。 但因为所有系统都是实时系统， 它是完全通用的。 @@ -320,8 +314,8 @@ B. 设计并记录模块结构 除非产品很小，小到能由单个程序员来做，否则我们必须考虑如何将工作分解为几个工作任务，即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责， 把我们的设计决策 (design decisions) 封装在各模块。 一个模块可以由多个子模块组成，也可以被视为单个工作任务。 -Page 11 ------------------------------------------------------------------------ +(Page 11) + 我们需要模块指南去避免重复，避免分歧，实现 **关注点分离 (Separation of Concerns)**，并且最重要的是，当对软件不熟悉的维护人员有一个问题报告时，去帮助他找出必须处理的模块。再一次，我们看到记录设计决定的文档与在维护阶段使用的文档是同一个文档。 @@ -333,8 +327,8 @@ C. 设计并记录模块接口 高效快速的软件生产需要程序员能够独立工作。模块指南定义了模块职责，但没有给出足够的信息去允许独立实现模块。每个模块必须规定精确的接口。为每个模块写一个 **模块接口规范 (Module Interface Specification)** ；规范必须正式，并提供每个模块的黑箱图片。规范由资深设计师撰写，并由潜在的接口实现者与会用到这些接口的程序员一起评审。 一个模块的接口规范只需包含足够信息使其他模块的程序员能够用该模块的功能即可，而不需要其他信息。 这也是模块实现者需要的信息。我们产生的文档被两者（其他模块的程序员、本模块实现者）使用。 -Page 12 ------------------------------------------------------------------------------- +(Page 12) + 虽然每个这样的文档都有一个人负责， 但是这些文档实际上是在模块实现者、模块使用者以及其他对设计感兴趣的人(例如评审员)协商过程中产生的。这些规范文件的主要内容有： @@ -361,8 +355,8 @@ D. 设计并记录模块内部结构 在某些情况下， 模块被简单地分成子模块并且子模块的设计文档是另一个模块指南，在这种情况下，那个模块的设计过程在上文B步骤处继续。 -Page 13 -------------------------------------------------------------------------------- +(Page 13) + 在其它情况下，我们从描述内部数据结构开始；在有些情况下，这些数据结构由子模块实现（并隐藏）。 对每个访问程序，我们包括一个函数 [10] 或者 LD-关系 [14], 用于描述它对数据结构的影响。对于模块返回给调用者的每个值，我们提供另外一个数学函数，这个数学函数叫做抽象函数，它将数据结构的值映射进返回值。对于每个意外事件，我们描述如何检查它。最后，我们提供一个"验证"，论证拥有这些属性的程序将会满足模块规约。 @@ -378,8 +372,8 @@ E. 设计并且记录使用层次 (uses hierarchy) （蓝珲注：本节提到的程序，容易引起混淆，其实就是指模块。二进制矩阵其实描述了模块之间的依赖关系。例如，有1,2,3,4四个模块，3依赖1, 1依赖2, 2依赖4，则{4}, {2,4}, {3,1}. {1,2,4}, {1,3,4},{1,2,3,4} 这些子集都可以各自组成独立程序，因为每个子集都包含了全部依赖，不必依赖与子集外面的东西。） -Page 14 ------------------------------------------------------------------------------- +(Page 14) + F. 编写程序 ```````````````````````````````````````````````````````````````````````````````` @@ -430,8 +424,8 @@ A． 当前的文档有什么问题？ 为什么它难用？ 为什么没有人 软件发生变化时，找不到所有文档对应的位置去修改。 -Page 15 ----------------------------------------------------------------------------- +(Page 15) + 这两种文档风格的问题都在于，除了作者之外，其他人找不到他们想要的信息。 因此，确定缺失的事实或纠正错误的事实并非易事。当软件更改时，要找到文档中应该更改的所有部分并非易事。 @@ -454,8 +448,8 @@ Page 15 在大型软件项目中，总会有新手。 -Page 16 ------------------------------------------------------------------------------- +(Page 16) + B. 如何避免这些问题？ @@ -469,8 +463,8 @@ B. 如何避免这些问题？ -Page 17 --------------------------------------------------------------------------------- +(Page 17) + 由此产生的文档不容易或能轻松阅读，但并不无聊。 我们用表格、公式和形式符号来增加信息密度。 @@ -495,8 +489,8 @@ Page 17 情发生的方式和事情的方式。 (见下文方子安处） -Page 18 ------------------------------------------------------------------------------------ +(Page 18) + VII. 现在， 我们如何佯装理想的过程？ `````````````````````````````````````````````````````````````````````````````` @@ -514,21 +508,18 @@ VII. 现在， 我们如何佯装理想的过程？ -Page 19 ----------------------------------------------------------------------------------- +(Page 19) 我们几年前为演示理想过程所写的软件需求文档，可作为这个过程取得成功的一个例证 [9]。通常，人们会假设需求文件是在编码前产生的，之后就不会再被使用了。 然而，事实证明并非如此。满足该需求文档的软件的原始版本，现在仍在修订。软件每次更改后，负责测试的机构大量使用这个文档来选择他们要做的测试。当需要新的改变时，需求文档被用于描述什么必须改变、什么不能改变。软件投入使用后，这个过程中产生的第一份文档一直被用了很多年。明确的消息是，如果文档精心制作，它将在很长时间都有用。反过来说，如果文档将被广泛使用，那么就值得把它写好。 成为一个理性的设计师很难，而且我们可能永远做不到。在我们尝试遵循这个过程当中，我们常发现在一些地方继承了一个没有明确理由的设计决策。 一个例子是我们要用的等式中的常数。当我们询问常量的推导时， 我们发现，要么推导不存在，要么推导无效。当进一步追问时，我们被告知做这个决策是“因为它起作用 ( **because it works** )”。在这种情况下，设计师可以立一个研究项目去找出为什么它起作用， 或简单地“与它友好相处 ( **Get On With It**) ”。为我们的工作付钱的人已经把 **GOWI** 作为对许多此类问题的标准回答，并且我们不认为真正的工作会有所不同。然而， 每当我们把“因为它们起作用”作为决策理由时，我们将记录这个坦诚的理由，而非误导以后的软件维护者去认为我们那么做有什么深刻的、哲学的理由。 -Page 20 ----------------------------------------------------------------------------------- +(Page 20) + **致谢** 来自美国海军研究实验室（NRL）的 Stuart Faulk 与 John Shore 为这篇文章提供了经过深思熟虑后的评论。 美国海军与加拿大NSERC对本研究提供了资助。 - - |