From b66a680619b62687b056d6fc627c99b73ae722b8 Mon Sep 17 00:00:00 2001 From: Hui Lan Date: Tue, 30 Jul 2019 16:00:50 +0800 Subject: =?UTF-8?q?parnas-a-rational-design-process.rst:=20=E6=8A=8A?= =?UTF-8?q?=E7=BF=BB=E8=AF=91=E4=BA=BA=E5=91=98=E7=9A=84=E5=90=8D=E5=AD=97?= =?UTF-8?q?=E4=BB=8E=E8=8A=82=E6=A0=87=E9=A2=98=E7=A7=BB=E5=88=B0=E8=8A=82?= =?UTF-8?q?=E5=86=85?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 为了方便阅读。 因为读者可能最感兴趣的不是谁翻译的， 而是内容。 --- parnas-a-rational-design-process.rst | 81 ++++++++++++++++++++++++++---------- 1 file changed, 60 insertions(+), 21 deletions(-) (limited to 'parnas-a-rational-design-process.rst') diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst index d1450c2..f074a8d 100644 --- a/parnas-a-rational-design-process.rst +++ b/parnas-a-rational-design-process.rst @@ -14,9 +14,10 @@ .. contents:: 内容目录 -通篇总结 - 伍泰炜 OK +通篇总结 ------------------------------------------------------------------------- +伍泰炜 读完全文之后，我感觉作者能把前面十几页的内容写出那么多字，真是十分了不 起，可能这就是科研工作者的特长吧，把一个东西反复讲述，使得论文的篇幅变 @@ -56,9 +57,11 @@ -Page 1 - 徐梦旗 OK +Page 1 ------------------------------------------ +(徐梦旗 翻) + 理性设计过程: 如何、为何要仿制它 摘要 @@ -74,9 +77,11 @@ Page 1 - 徐梦旗 OK -Page 2 - 田遍地 OK +Page 2 ---------------------------------------------------------- +(田遍地 翻) + 理性设计过程: 如何、为何要仿制它 **David L.Parnas** - 加拿大维多利亚大学计算机科学系，美国华盛顿海军研究实验室计算机科学和系统分支 @@ -100,9 +105,11 @@ I. 寻找哲人之石： 为什么要理性设计过程？ -Page 3 - 徐闰钞 OK +Page 3 ----------------------------------------------- +(徐闰钞 翻) + （所有可以被归类为“自顶向下”的方法都是我们希望有一种合理又系统的软件设计方法的结果。） 本文既带来坏消息，也带来好消息。坏消息是，在我们看来，我们永远找不到哲 @@ -134,9 +141,11 @@ II. 为什么软件设计“过程”总是理想化？ -Page 4 - 吴贞娴 OK +Page 4 ------------------------------------------------------------------- +(吴贞娴 翻) + 5. 用人就会有人为错误。无论我们的决策过程多么理性，无论我们的相关事实 收集和组织多么好，我们都将会犯错。 @@ -165,9 +174,11 @@ III . 尽管如此， 为什么描述理性理想化过程是有用的呢? -Page 5 - 余慧 OK +Page 5 --------------------------------------------------------------- +(余慧 翻) + （与吴贞娴翻译的最后一段同： 上文所提及的内容，很明显为每个深思熟虑过 的人所知、为坦诚的人所承认。尽管如此，我们仍旧能看到以软件设计过程为主 题的会议、研究软件设计方法论的工作小组，以及为了丰厚市场利益扬言能描述 @@ -198,9 +209,11 @@ Page 5 - 余慧 OK -Page 6 - 魏含饴 OK +Page 6 -------------------------------------------------------------------------- +(魏含饴 翻) + 5． 外部人员对项目进展定期审查对良好的管理不可或缺。 如果项目试图紧随 理想过程，审查就会更容易。 @@ -234,9 +247,11 @@ V． 理性设计过程是什么？ 每一个工作产品的审查以及对生成的可执行代码的测试。 -Page 7 - 叶红霞 OK +Page 7 --------------------------------------------------------------------- +(叶红霞 翻) + （在实施本文描述的过程时，我们对每一个工作产品进行了广泛而系统的审查， 并对生成的可执行代码进行了测试。） @@ -272,9 +287,11 @@ A. 建立并记录需求 - 在系统投入使用长时间后，需求文档可以用于为将来的需求变更定义约束条件。 -Page 8 - 王如韵 OK +Page 8 -------------------------------------------------------------------------- +(王如韵 翻) + - 它可以解决争议; 我们不再需要成为应用程序专家或咨询应用程序专家。 因为通常没有组织良好的信息来源， 确定详细的需求很可能是这个过程中最困 @@ -300,9 +317,11 @@ Page 8 - 王如韵 OK -Page 9 - 蒋佳玲 OK +Page 9 --------------------------------------------------------------------- +(蒋佳玲 翻) + 我们通过把关注点分离（ **Separation of Concerns** ）到章节，来获得需求 文档的完整: @@ -325,9 +344,11 @@ Page 9 - 蒋佳玲 OK -Page 10 - 应舸 OK +Page 10 ---------------------------------------------------------------------------- +(应舸 翻) + 为确保文档的一致性与完整性， 文档组织结构背后必须有一个简单的数学模型。 我们的模型是由我们在实时系统上的工作所启发的。 但因为所有系统都是实时系统， 它是完全通用的。 我们假设， 对于实时控制系统来说，理想的产品不是纯数字计算机，而是混合计算机。 混合计算机由控制模拟计算机的数字计算机组成。 模拟计算机将输入的连续值转换为连续输出。 当离散事件发生时，数字计算机给由模拟计算机计算的函数带来离散变化？？？。 实际的系统是该混合系统的数字近似。 与其他工程领域一样，写软件规范时， 我们首先描述“理想”系统， 然后指定允许的误差。 在需求文档中， 我们认为， 输出重要性高于输入。 如果输出值是正确的，即使我们不读取输入，也没人会介意。 因此，在过程第一阶段，关键是 **识别所有输出** 。 我们的需求文档， 其核心是由表格形式表示的数学函数集合。 每个函数都有一组外部状态变量， 且输出单个值。 文献 [8]中给出了以这种方式生成的完整文档例子， [9]中对该例子有讨论。 @@ -340,9 +361,11 @@ B. 设计并记录模块结构 除非产品很小，小到能由单个程序员来做，否则我们必须考虑如何将工作分解为几个工作任务，即模块。 此阶段应生成的文档为 **模块指南 (Module Guide)** 。 模块指南定义各模块的职责， 把我们的设计决策 (design decisions) 封装在各模块。 模块里可以有子模块，也可以单独作为一个工作任务。 -Page 11 - 徐焕众 OK +Page 11 ----------------------------------------------------------------------- +(徐焕众 翻) + 模块指南用来避免重复，避免空隙，实现 **关注点分离 (separation of concerns)** 。 最重要的， 当产品有问题时， 用来帮助维护人员找出对应的模块。 记录设计决策的文档与在维护阶段使用的文档是同一个文档。 如果我们努力地将信息隐藏 (information hiding) 或 关注点分离 (separation of concerns) 应用于大型系统，那么肯定会产生大量模块。 没有其他结构，只是简单列出模块名的指南，只对熟悉系统的人有帮助。 而我们的模块指南是树形结构的， 它将系统划分成几大模块，并以相同的方式细分每个模块，直到所有模块都非常小为止。 这种文档的例子， 参见[3]。 对这一办法及其好处的讨论，参见[15，6]。 @@ -353,9 +376,10 @@ C. 设计并记录模块接口 高效快速的软件生产需要使程序员能独立工作。 模块指南定义了模块职责，但没有给出足够的信息使得每个人能去独立实现模块。 为此，每个模块必须指定精确的接口。 每个模块都必须有 **模块接口规范 (Module Interface Specification)** ； 规范必须正式，并提供每个模块的黑箱图片 (black box picture)。 规范由资深设计师撰写， 并由接口实现者与接口使用者一起评审。 一个模块的接口规范只需包含足够使其他模块的程序员使用该模块功能的信息， 而不需要其他信息。 接口实现者也需要 **模块接口规范** 。· 我们写的文件由两者使用。 -Page 12 - 何可人 OK +Page 12 ------------------------------------------------------------------------------ +(何可人 翻) 虽然，每人负责写一个文件， 但这些文件实际上是在模块实现者、模块使用者， 对模块设计感兴趣的人（如审稿人）商议过程中产生的。 这些规范文件的主要内容有： @@ -380,9 +404,10 @@ D. 设计并记录模块内部结构 在某些情况下， 模块只是被简单地分成几个子模块， 设计文件是另一个模块指南。 在这种情况下，该模块的设计过程在上面的步骤 B_ 处继续。 -Page 13 - 袁世家 OK +Page 13 ------------------------------------------------------------------------------- +(袁世家 翻) 在另一些情况下，我们从描述内部数据结构开始； 还有一些情况是， 这些数据结构被子模块实现（并隐藏）。 对于每个被访程序，我们包括一个函数 [1] 或者 LD-关系 [14], 用来描述对数据结构的影响。 对于模块返回给调用者的每个数值，我们提供叫做抽象函数的数学函数，这个函数将数据结构的值映射到返回值？？？。 对于每个意外事件， 我们描述了怎样去检查发现它。 最后，我们还提供一个"验证"， 一个拥有这些属性的程序会满足模块说明的论据？？？。 @@ -397,9 +422,11 @@ E. 设计并且记录使用层级 (uses hierarchy) （蓝珲的理解： 文中提到的程序， 容易引起混淆， 其实就是模块。 真值矩阵其实描述了模块之间的依赖关系。 例如， 有1,2,3,4四个模块， 3依赖1, 1依赖2, 2依赖4。 {4}, {2,4}, {1, 2, 4}, {3,1,2,4} 这些子集都可以组成独立程序。） -Page 14 - 陈肖飞 OK +Page 14 ------------------------------------------------------------------------------ +(陈肖飞 翻) + F. 编写程序 ```````````````````````````````````````````````````````````````````````````````` @@ -428,9 +455,11 @@ A． 当前的文档有什么问题？ 为什么它不便使用？ 为什么它 -Page 15 - 陈俊蕾 OK +Page 15 ---------------------------------------------------------------------------- +(陈俊蕾 翻) + 文档中多余的注解是没必要的，且会使系统维护变得更加昂贵。 除此之外，还 会增加代码与原文档不符的可能性。 @@ -455,9 +484,11 @@ VI. 文件在此过程中充当什么样的角色？ -Page 16 - 王海榕 OK +Page 16 ------------------------------------------------------------------------------ +(王海榕 翻) + 如何避免这些问题？ 理想设计过程中， 文档既满足了开发人员需求， 也满足了维护人员的需求。上 @@ -486,9 +517,11 @@ execution)”， 我们花大力气来设计每个文件的结构。 通过声 -Page 17 - 周佳威 OK +Page 17 -------------------------------------------------------------------------------- +(周佳威 翻) + 这样生成的文档读起来不容易、不轻松，但也不枯燥。 我们用表格、公式和正式符号来增加信息密度。 我们文档结构规则避免了信息重复。 这样的文档必须聚精会神地读， 但是会回馈给读者以详细准确的信息。 为避免传统文档遍布着混淆的与不一致的术语的情况， 我们用一种由特殊括号与类型字典组成的术语系统。 每个必须定义的术语都被嵌在一对括号符号中， 括号符号反应了术语的类型。 对每个类型，我们有一个字典， 字典包含了对该类型的定义。 虽然刚开始阅读我们文档的读者会觉得 !+terms+!、 %terms%、 #terms# 这些符号干扰了阅读， 但是经常读我们文档的用户会觉得这些特殊括号隐含的类型信息反而会使阅读变容易。 类型字典减少了我们为同一个概念定义两个术语， 或者为同一个术语给出两个定义的可能。 特殊括号对已经引入但但未定义， 或已定义但从未使用过的术语进行机械检查变得容易。 @@ -504,9 +537,11 @@ Page 17 - 周佳威 OK 情发生的方式和事情的方式。 (见下文方子安处） -Page 18 - 方梓安 OK +Page 18 ----------------------------------------------------------------------------------- +(方梓安 翻) + VII. 现在， 如何假装理想的过程？ `````````````````````````````````````````````````````````````````````````````` @@ -536,17 +571,21 @@ VII. 现在， 如何假装理想的过程？ -Page 19 - 刘莉莉 OK +Page 19 ---------------------------------------------------------------------------------- +(刘莉莉 翻) + 几年前我们写了一个软件需求文件，作为对理想过程演示的一部分，这个需求文件说明了这个过程是值得的[9]。 通常，人们认为需求文件是在编码前写成的， 编码完成后就不会再被使用了。 然而，事实证明并非如此。 那些满足我们的需求文件的软件， 它的初始版本仍在被修订。 每次更改软件后， 软件测试机构大量使用这个需求文件来选择他们的测试。 当需要新更改时， 用需求文件描述什么必须被改变、什么必须不变。 软件投入使用很多年后， 该过程中产生的第一份文件至今还在被使用。 可以明确的是，如果文件是经过精心制作的， 它将在很长时间内都有用。 如果文件将被大量使用，那么正确制作它很值得。 成为一个理性的设计师很难，而且我们可能永远做不到。 在我们尝试遵循这个过程当中，我们常发现继承了某设计决策， 却不知道当初决策者的之所以决定的理由。 一个例子是等式中常量的值。当我们要常量的推导过程时， 我们发现它不存在、或者原先推导是不正确的。 当进一步追问时，我们被告知做这个决策是 “因为它起作用 ( **because it works** )”。 在这种情况下，设计师可以去研究它起作用的原因， 或者就简单地 “与它友好相处 ( **Get On With It (GOWI)**) ”。 给我们的工作付钱的人把 **GOWI** 作为对许多此类问题的标准回答。 我们并不认为真正的工作会有所不同。 然而， 每当我们把“因为它们起作用”作为决策理由时， 我们就诚实地把这个理由写下来， 以免误导将来的软件维护者去花心思想在我们的决策后面有什么深刻的理由。 -Page 20 - 蓝珲 OK +Page 20 ---------------------------------------------------------------------------------- +(蓝珲 翻) + **致谢** NRL的Stuart Faulk与John Shore为这篇文章提供了深思熟虑后的评论。 -- cgit v1.2.1