diff options
| -rw-r--r-- | parnas-a-rational-design-process.rst | 36 |
1 files changed, 0 insertions, 36 deletions
diff --git a/parnas-a-rational-design-process.rst b/parnas-a-rational-design-process.rst index e0da74b..55e53d1 100644 --- a/parnas-a-rational-design-process.rst +++ b/parnas-a-rational-design-process.rst @@ -17,8 +17,6 @@ 通篇总结 ------------------------------------------------------------------------- -伍泰炜 - 读完全文之后，我感觉作者能把前面十几页的内容写出那么多字，真是十分了不 起，可能这就是科研工作者的特长吧，把一个东西反复讲述，使得论文的篇幅变 得很长，让人看起来好像内容很多。 @@ -60,8 +58,6 @@ Page 1 ------------------------------------------ -... (徐梦旗 翻) - 理性设计过程: 如何、为何要佯装它 @@ -95,8 +91,6 @@ Page 1 Page 2 ---------------------------------------------------------- -... (田遍地 翻) - I. 寻找魔法石： 我们为什么想要理性设计过程？ ````````````````````````````````````````````````````````````` @@ -118,7 +112,6 @@ I. 寻找魔法石： 我们为什么想要理性设计过程？ Page 3 ----------------------------------------------- -(徐闰钞 翻) 本文同时带来了好消息和坏消息。坏消息是，在我们看来，我们将永远找不到魔法石。 我们将永远找不到能让我们以完美地理性方式去设计软件的过程。好消息是我们 @@ -150,7 +143,6 @@ II. 为什么软件设计“过程”总是理想化？ Page 4 ------------------------------------------------------------------- -(吴贞娴 翻) 5. 除非不用人，否则无法避免人为错误（Human Errors）。无论我们的决策过程多么理性，无论我们对相关事实 的收集与组织有多好，我们都会犯错。 @@ -179,8 +171,6 @@ III . 尽管如此， 为什么描述理性的理想化过程有用呢? Page 5 --------------------------------------------------------------- -(余慧 翻， 刘义青 改， 董峻玮 改) - .. （与吴贞娴翻译的最后一段同： 上文所提及的内容，很明显为每个深思熟虑过 的人所知、为坦诚的人所承认。尽管如此，我们仍旧能看到以软件设计过程为主 @@ -205,7 +195,6 @@ Page 5 Page 6 -------------------------------------------------------------------------- -(魏含饴 翻) 5． 外部人员对项目进展定期审查对良好的管理是必不可少的。 如果项目正试图遵循理想过程，审查将会更容易。 @@ -241,7 +230,6 @@ V． 理性设计过程是什么？ Page 7 --------------------------------------------------------------------- -(叶红霞 翻， 汪杰 改) （在实施本文描述的过程时，我们对每一个工作产品进行了广泛而系统的审查， 并对生成的可执行代码进行了测试。） @@ -276,8 +264,6 @@ A. 建立并记录需求 Page 8 -------------------------------------------------------------------------- -(王如韵 翻， 吴逸嘉 改) - - 它可以用于平息争论; 我们不再需要成为或咨询应用专家。 确定详细的需求可能是这个过程中最困难的部分，因为通常没有有条理的信息来源。理想情况下，需求文档应由未来用户代表来写。实际上，它可能将由软件设计者来产生，然后由用户代表们同意。 @@ -299,8 +285,6 @@ Page 8 Page 9 --------------------------------------------------------------------- -(蒋佳玲 翻，胡刚强 改，周婧哲 改) - 通过使用关注点分离（ **Separation of Concerns** ）获得以下部分，我们达到需求文档的完整性: - 运行软件的机器的规范。机器不必是硬件 -- 对于一些系统，这一节可能仅仅指向一个语言参考手册； @@ -325,8 +309,6 @@ Page 9 Page 10 ---------------------------------------------------------------------------- -(应舸 翻) - 为确保文档的一致性与完整性， 文档组织结构背后必须有一个简单的数学模型。 我们的模型是由我们在实时系统上的工作所启发的。 但因为所有系统都是实时系统， 它是完全通用的。 我们假设，对于实时控制系统，理想的产品不是纯数字计算机，而是混合计算机，它由控制模拟计算机的数字计算机组成。 模拟计算机将输入的连续值转换为连续输出。 当离散事件发生时，数字计算机使由模拟计算机计算的函数发生离散变化。 实际的系统是该混合系统的数字近似。 与其他工程领域一样，写软件规范时， 我们首先描述“理想”系统， 然后指定允许的误差。 在需求文档中， 我们认为， 输出重要性高于输入。 如果输出值是正确的，即使我们不读取输入，也没人会介意。 因此，在过程第一阶段，关键是 **识别所有输出** 。 我们的需求文档， 其核心是由表格形式表示的数学函数集合。 每个函数将单个输出的值指定为与应用程序相关的外部状态变量的函数。 文献 [9] 中给出了以这种方式生成的完整文档例子， [8]中对该例子有讨论。 @@ -342,8 +324,6 @@ B. 设计并记录模块结构 Page 11 ----------------------------------------------------------------------- -(徐焕众 翻， 邱嘉吉 改善) - 我们需要模块指南去避免重复，避免分歧，实现 **关注点分离 (Separation of Concerns)**，并且最重要的是，当对软件不熟悉的维护人员有一个问题报告时，去帮助他找出必须处理的模块。再一次，我们看到记录设计决定的文档与在维护阶段使用的文档是同一个文档。 如果我们勤勉地将信息隐藏 (information hiding) 或关注点分离 (separation of concerns) 应用于大型系统，那么最终肯定会有大量模块。只是简单列出模块名而没有其它结构的指南，只会对熟悉系统的人有帮助。 我们的模块指南有一个树形结构，它将系统划分成少量几个模块，并以相同的方式细分每个模块，直到所有模块都非常小为止。 这种文档的完整例子， 见[3]。 对这一办法以及其好处的讨论，见[15，6]。 @@ -357,8 +337,6 @@ C. 设计并记录模块接口 Page 12 ------------------------------------------------------------------------------ -(何可人 翻) - 虽然每个这样的文档都有一个人负责， 但是这些文档实际上是在模块实现者、模块使用者以及其他对设计感兴趣的人(例如评审员)协商过程中产生的。这些规范文件的主要内容有： - 可被其他模块的程序调用的程序列表，（叫做访问程序 (access program)）； @@ -387,8 +365,6 @@ D. 设计并记录模块内部结构 Page 13 ------------------------------------------------------------------------------- -(袁世家 翻， 卢梦茹 改， 李润超 改) - 在其它情况下，我们从描述内部数据结构开始；在有些情况下，这些数据结构由子模块实现（并隐藏）。 对每个访问程序，我们包括一个函数 [10] 或者 LD-关系 [14], 用于描述它对数据结构的影响。对于模块返回给调用者的每个值，我们提供另外一个数学函数，这个数学函数叫做抽象函数，它将数据结构的值映射进返回值。对于每个意外事件，我们描述如何检查它。最后，我们提供一个"验证"，论证拥有这些属性的程序将会满足模块规约。 我们继续分解与设计子模块，直到每个工作任务足够小，小到即便负责这个模块的程序员离开了项目，我们也可以承担放弃它并重新开始的代价。 @@ -406,8 +382,6 @@ E. 设计并且记录使用层次 (uses hierarchy) Page 14 ------------------------------------------------------------------------------ -(陈肖飞 翻， 季敬超 改) - F. 编写程序 ```````````````````````````````````````````````````````````````````````````````` @@ -484,8 +458,6 @@ Page 15 Page 16 ------------------------------------------------------------------------------ -(王海榕 翻，张俊玲 改) - B. 如何避免这些问题？ 在理想设计过程中的文档满足开发人员需求，也满足后来的维护程序员的需求。上面提到的每个文件都记录了设计决策，并在其余的设计中被用作参考文件。然而，它们也提供了维护者将需要的信息。因为这些文件在整个软件构建过程中被用作参考手册，它们将是成熟的，并且在以后的工作中随时可用。 它们将总是最新的。 我们设计过程中的文档不是事后的想法；它被视为项目的主要产品之一。 可以做一些检查来增加其完整性和一致性。 @@ -501,8 +473,6 @@ B. 如何避免这些问题？ Page 17 -------------------------------------------------------------------------------- -(周佳威 翻) - 由此产生的文档不容易或能轻松阅读，但并不无聊。 我们用表格、公式和正式符号来增加信息密度。 我们的结构规则避免了信息重复。 @@ -529,8 +499,6 @@ Page 17 Page 18 ----------------------------------------------------------------------------------- -(方梓安 翻， 欧阳芳 改) - VII. 现在， 我们如何佯装理想的过程？ `````````````````````````````````````````````````````````````````````````````` @@ -550,8 +518,6 @@ VII. 现在， 我们如何佯装理想的过程？ Page 19 ---------------------------------------------------------------------------------- -(刘莉莉 翻， 王蓉 改) - 我们几年前为演示理想过程所写的软件需求文档，可作为这个过程取得成功的一个例证 [9]。通常，人们会假设需求文件是在编码前产生的，之后就不会再被使用了。 然而，事实证明并非如此。满足该需求文档的软件的原始版本，现在仍在修订。软件每次更改后，负责测试的机构大量使用这个文档来选择他们要做的测试。当需要新的改变时，需求文档被用于描述什么必须改变、什么不能改变。软件投入使用后，这个过程中产生的第一份文档一直被用了很多年。明确的消息是，如果文档精心制作，它将在很长时间都有用。反过来说，如果文档将被广泛使用，那么就值得把它写好。 成为一个理性的设计师很难，而且我们可能永远做不到。在我们尝试遵循这个过程当中，我们常发现在一些地方继承了一个没有明确理由的设计决策。 一个例子是我们要用的等式中的常数。当我们询问常量的推导时， 我们发现，要么推导不存在，要么推导无效。当进一步追问时，我们被告知做这个决策是“因为它起作用 ( **because it works** )”。在这种情况下，设计师可以立一个研究项目去找出为什么它起作用， 或简单地“与它友好相处 ( **Get On With It**) ”。为我们的工作付钱的人已经把 **GOWI** 作为对许多此类问题的标准回答，并且我们不认为真正的工作会有所不同。然而， 每当我们把“因为它们起作用”作为决策理由时，我们将记录这个坦诚的理由，而非误导以后的软件维护者去认为我们那么做有什么深刻的、哲学的理由。 @@ -560,8 +526,6 @@ Page 19 Page 20 ---------------------------------------------------------------------------------- -(蓝珲 翻) - **致谢** 来自美国海军研究实验室（NRL）的 Stuart Faulk 与 John Shore 为这篇文章提供了经过深思熟虑后的评论。 |