EEPW论坛

设计过程,面向对象的软件设计。 出处 http://www.npc6.com/doc_commend/doc_software.htm （软件）设计方法 作者:Larry Brinn 翻译: CKER 1. 简介 2. （软件）设计是什么？ 3. （软件）设计过程 4. （软件）设计基础 5. （软件）设计方法论 6. （软件）设计文档 7. 面向对象的（软件）设计 8. 结论 简介 您是如何开始一个新工程的？是不是跳到计算机前，打开您喜爱的 RAD 工具开始输入代码？有没有想过程序会执行些什么或者系统是如何操纵数据的？有没有想过要记下些东西来帮助提醒您或阐明您已经开发的代码的逻辑实现？如果您对第一个问题答 " 不 " ，而其他问题答 " 是 " 的话，您可以跳过这篇文档。否则的话，请 好好读读 这篇文章。您应该有个计划、蓝图，并且在手边有个对您的问题解决方案的简明安排。 " 您必须知道您要去哪儿得到一切！ " 让我们来看看开发一个能实现您所设计的功能的程序时，什么最棘手。 （软件）设计是什么？ E.S. Taylor 给设计下的定义是 : " …the process of applying various techniques and principles for the purpose of defining a device, a process or a system in sufficient detail to permit its physical realization. " " … 应用各种各样的技术和原理，并用它们足够详细的定义一个设备、一个程序或系统的物理实现的过程。 " 对任意的工程产品或系统，开发阶段绝对的第一步是确定将来所要构建的制造原型或实体表现的目标构思。这个步骤是由多方面的直觉与判断力来共同决定的。这些方面包括构建类似模型的经验、一组引领模型发展的原则、一套启动质量评价的标准、以及重复修改直至设计最后定型的过程本身。计算机软件设计与其他工程学科相比还处在幼年时期，仍在不断变化中，例如更新的方法、更好的算法分析、以及理解力的显著进化。软件设计的方法论的出现也只有三十年多一点，仍然缺乏深度、适应性和定量性质，通常更多的与经典工程设计学科相联系。尽管如此，现今的软件技术已经存在、设计质量的标准也可使用、设计符号亦可以应用。带着这些意见，我们一起来看看什么有助于程序员们找到他们的软件涅盘 ( 天堂的意思 ) 。 （软件）设计过程 软件的设计是一个将需求转变为软件陈述（表达）的过程。这种陈述给我们一个对软件的全局观点。系统通过逐步求精使得设计陈述逐渐接近源代码。这里有两个基本步骤；第一步是 初步设计 Preliminary design ，关注于如何将需求转换成数据和软件框架。第二步是 详细设计 Detail design ，关注于将框架逐步求精细化为具体的数据结构和软件的算法表达。发生中的设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计这一清晰的行为来结合起来。 界面设计 Interface design 建立程序布局和人机交互机制。贯穿设计过程的质量由一系列的 正式技术评定 formal technical reviews 或 设计排演 design walkthroughs 来评价。良好的设计规范必须建立在对设计陈述（表达）的评估之上，以下是一些指导方针： 1. 设计应该展现层次结构使得软件各部分之间的控制更明智。 2. 设计应当模块化；这就是说，软件应在逻辑上分割为实现特定的功能和子功能的部分。 3. 设计应当由清晰且可分离的数据和过程表达来构成。 4. 设计应使得模块展现独立的功能特性。 5. 设计应使得界面能降低模块之间及其与外部环境的连接复杂性。 6. 设计应源自于软件需求分析期间获得的信息所定之可重复方法的使用。 要拥有良好的设计特征不是靠碰运气，而在设计过程中通过综合运用基础设计原理、系统方法论、彻底的评定回顾可以有助于良好的设计。软件设计方法每天都在进化，作为已经经过测试和细化的方法，良好的设计应具有以下的四种特性，并在所有这些特性之间保持一致。 1. 将信息领域的表达转换为软件设计的表达的机制。 2. 表示功能组件及其界面的符号。 3. 逐步求精和分割的试探。 4. 质量评估的指导方针。 开发软件的时候，不管采用何种设计方法您必须能够熟练运用一套关于数据、算法和程序设计的基本原理。 （软件）设计基础 软件设计方法论的这套基本原理已经经过了多年的进化。每种概念的影响程度不尽相同，但它们都经历了时间的洗礼。基于这些基本原理设计者可以采用更多更成熟的设计方法。这些基本原理有助于设计者回答以下的问题： 1. 将软件分割成独立的组件时会采用何种标准？ 2. 怎样将软件的原则性表示详细分割成函数或数据结构？ 3. 有没有定义一个软件设计的技术质量的统一标准？ M.A. Jackson 曾经说过： " 对一个计算机程序员来说，分辨让程序运行和让程序 正确 之间的差异是一个良好的开端。 " 为了 " 使程序 正确 " ，基本设计原理提供了必须的框架。因此让我们来对这些基本原理作个简短的检视。 抽象 Abstraction 在最高层次上指的是使用待解决的问题领域内的术语描述的解决方案。相对较低层次的抽象则更多的面向程序语言，最低层的抽象则是解决方案的可直接实现的方式描述。软件设计的每一个步骤都是对相应层次解决方案的抽象的逐步求精。 求精 Refinement 又叫做逐步求精指的是通过程序细节连续细化来开发程序体系的策略。分步骤的对程序抽象进行分解直至成为编程语言的过程同时造就了程序的层次结构。在这一点上要对细节多做考虑，这也展示了求精实际上是个苦心经营的过程。 模块化 Modularity 指的是软件可被分割为分别命名并可寻址的组件（也叫做模块），将模块综合起来又可以满足问题的需求的性质。 " 软件的模块化是允许智能化管理程序的唯一属性。 " 换句话说，当您将一个复杂问题分解为一些小问题时会更容易解决。需要重点解释的是即使一个系统必须象 " 单片机 " 一样来实现，它也可以采用模块化设计。 软件体系（架构） Software Architecture 涉及到程序的两个重要特性： 1) 模块的层次结构。 2) 数据结构 。这源自于需求分析时将真实世界问题的含蓄定义与软件解决方案的要素关联起来的分割过程。当问题的每个部分通过一个或多个软件要素得到解决后，与问题的定义和解决相一致软件和数据结构的进化就开始了。这个过程代表了软件的需求分析和设计之间的位置。 控制层级 Control Hierarchy 也称作程序结构，描述程序组件的组织并意味着控制层级。它并不描述软件的程序方面，比如进程顺序、决定的事件 / 命令、或工作循环。如下的层级图表展示了模块之间的通信流，并显示哪些模块是重复的（右上角变黑的块）。这个图表描述了一个能够读文件，计算每个记录的值并书写报表来显示记录的信息和所完成的计算。 数据结构 Data structure 描述了单个数据间的逻辑关系。数据结构规定了数据的组织、访问方法、关联程度、和信息的选择处理。数据结构的组织和复杂性只受限于设计者的灵活性。唯一的限制就是经典数据结构的数量阻碍了更多的久经考验的结构出现。 软件程序 Software Procedure 着重于处理每个模块的细节并必须提供一个精确的处理规范，包括事件顺序、准确的判定点、重复操作、甚至数据结构。软件的程序表现是分层的，处理方法应该包括其所有子模块的参考。 信息隐藏 Information Hiding 的法则建议 由设计决定所刻划的模块特性应该对其余的模块不可见 。换句话说，模块应被设计和指定为包含在模块内部且其他模块不可访问的内容对其他模块来说是无需的。隐藏意味着有效的模块性能够通过定义一套独立的模块来实现，这些模块相互之间的通信仅仅包括实现软件功能的所必须的信息。将使用信息隐藏作为设计标准在测试或今后的维护期间需要修改系统时带来了最大的好处。 （软件）设计方法论 让我们来遍历设计过程中用以促成模块化设计的四个区域： 模块 Modular 、数据 Data 、体系 Architectural 和 程序 Procedural 设计。 模块设计 Modular design 减低了复杂性、便于修改、且使得支持系统不同部分的并行开发实现起来更容易。模块类型提供的操作特性通过结合时间历史、激活机制、和控制模式来表现。在程序结构内部，模块可以被分类为： 1. 顺序 sequential 模块，由应用程序引用和执行，但不能从表观上中断。 2. 增量 incremental 模块，可被应用程序先行中断，而后再从中断点重新开始。 3. 并行 parallel 模块，在多处理器环境下可以与其他模块同时执行。 单独的模块更容易开发，因为功能可以被划分出来，而界面只是用来确保功能的独立。功能的独立性可以使用两个定性的标准来衡量： 凝聚性 cohesion －衡量模块的功能强度的相关性，和 耦合性 coupling －衡量模块间的相互依赖的相关性。 数据设计 Data design 首先并且有些人也坚信，是最重要的设计行为。数据结构的影响和程序上的复杂性导致数据设计对软件质量有着深远的影响。这种质量由以下的原理来实施： 1. 适用于功能和行为分析的系统分析原理同样应该适用于数据。 2. 所有的数据结构，以及各自所完成的操作都应该被确定。 3. 创建数据词典并用来详细说明数据和程序的设计。 4. 底层的数据设计决定应该延迟至设计过程的后期。 5. 数据结构的陈述（具体说明）应该只被那些直接使用包含在此结构内的数据的模块所知道。 6. 有用的数据结构和操作库可以在适当的时候使用。 7. 软件设计和编程语言应该支持抽象数据类型的规范和实现。 体系设计 Architectural Design 的主要目标是开发模块化的程序结构并表达出模块间的控制相关性。另外，体系设计融合了程序结构与数据结构，以及使得数据得以在程序中流动的界面定义。这种方法鼓励设计者关注系统的整体设计而不是系统中单独的组件。选用不同的方法会采用不同的途径来接近体系的原点，但所有这些方法都应该认识到具有软件全局观念的重要性。 程序设计 Procedural Design 在数据、程序结构、和陈述详细算法的说明都已使用类似英语的自然语言来呈现后，再确定程序设计。使用自然语言来陈述的原因是当开发小组的绝大多数成员使用自然语言来交流的话，那么小组外的一个新手在不经学习的情况下会更容易理解这些说明。这里有个问题：程序设计必须毫无歧义的来详细说明程序，但我们都知道不含糊的自然语言也就不自然了。 （软件）设计文档 在任何系统中，开发文档都是有价值的东西。现在已经有许多不同的经过发展的文档计划可供您在创建系统时候进行选择。其中相当不错的一种模型就是所谓的设计规范 （译者注：此处原有的超链接已经失效，所以无法得到其原始的模板。但 CKER 还有一套被称作的 APM 的文档模板似乎不错。以后也许会翻给大家来看看 ……^_^ ） 。 当您察看此文档的大纲的时候 , 请注意各级别的详细内容。 第一部分展示了源自于系统说明和其他定义文档的设计成果的总体范围。第二部分展示的是涉及支持文档的详细说明。第三部分的内容又称作设计描述，在初步设计阶段完成。第四、五部分的内容将初步设计阶段的内容发展至详细设计阶段。第六部分展示了确保以下两条原则的交叉参考矩阵： 1. 用软件设计满足所有的需求。 2. 指出实现特定需求的关键模块。 第七部分在开发测试程序（步骤）的第一步对系统的功能性和正确性进行测试是必要的。如果在开发设计规范的同时已经并行开发了详细的测试程序规范的话，本部分可以删除。第八部分详细说明了将系统打包传送至用户站点的考虑和要求。在文档剩下的第九、十部分中包括了算法描述、选择程序、列表数据、流程图、伪代码、数据流图表、以及所有在设计规范开发时所用到的相关信息都可以放在此处。 面向对象的（软件）设计 到目前为止我们所详细说明的一切都是如今在 IT 领域被广泛使用的设计方法论的基石。面向对象的设计（ OOD ）通过模块化信息及其加工方法而不单单是加工方法来让数据对象和加工操作得以互相连接。这个过程依赖于三个极其重要的设计概念：抽象、信息隐藏、和模块化。所有的设计方法都力争展现这些特性；但只有 OOD 的机制才能使设计者能够无需增加复杂性或加以折衷就获得所有三种特性。在 OOD 中，我们有 objects （对象） , operations （操作） ,和 messages （消息） 。 Objects （对象 ） , 又称作类，可以是人、机器、命令、文件、汽车、房子，等等。 operations （操作） , 包含了私有的数据结构和用于变换数据结构的加工方法。 messages （消息） 用于激活调用操作控制和对象的程序构造。这就是说对象的共享部分是其的接口而消息在接口之间移动并指定希望使用对象的何种操作，但并不知道操作是怎样具体实现的。对象在收到消息之后决定如何来执行消息。现在让我们来看看在面向对象的系统中的某些工具是如何使用的： 1. 伪代码 － 接近计算机编程语言的指令，但使用的是近似英语的语言而不是真正的编程语言以便于查看程序逻辑。下面是一个加工文件中的记录的范例 : Start ( 开始 ) Initialize program ( 初始化程序 ) Read a record ( 读一个记录 ) Process record ( 加工记录 ) Move record to print area ( 将记录移至打印区 ) Write a line ( 写一行 ) End job ( 结束任务 ) Stop run. ( 停止运行 ) 2. 原型 － 在开发软件包的第一个版本或模型，或者计算机硬件准备好作生产前测试时的步骤。通常可以使用您所喜爱的 RAD 工具来创建。 3. TOE 图表 － (Task 任务 , Object 对象 , Event 事件 图表 ) 用来展示需要完成的任务或工作、执行工作的对象、以及完成此过程的事件或动作。请看下面将两个数相加的 TOE 图表： 任务 对象 事件 启动程序 Main Form OnStartup 输入第一个数 EdtFirstNumber User types in 输入第二个数 EdtSecondNumber User types in 求和 EdtResult OnClick 程序退出 BtnExit OnClick 正如您在上例中所见，这正确说明了要执行什么、谁来执行、以及什么时候来执行。 正如一开始所说的 " 您必须知道您要去哪儿得到一切 " ，并且遵循特定的路径或方法可以给您所需的信心来实现您试图开发的系统。有很多方法可以遵循，在这里只想说几句话：您应该采用能被小组和您自己都能接受的方式。您所选择的方式应该让所有您计划中可能使用的人感觉简单明了和易于理解。试试在您的头脑中记住后面这个缩写的意义： KISS (Keep It Short and Simple)<让您的代码保持短小简单> 。 设计时的参考良书: "Software Engineering, A practitioner's approach 3rd edition", by Roger S. Pressman." "Object-Oriented Design", by Peter Coad and Edward Yourdon"