来源:ChinaUnix.net作者:ChinaUnix.net 发布时间:2008-04-11 06:31:14


[size=18:4b927fde27][color=darkblue:4b927fde27][b:4b927fde27]Larry Brinn谈(软件)设计方法(CKer)[/b:4b927fde27][/color:4b927fde27][/size:4b927fde27]
出处: http://www.npc6.com/doc_commend/doc_software.htm
(软件)设计方法
作者:Larry Brinn 翻译: CKER
1. 简介
2. (软件)设计是什么?
3. (软件)设计过程
4. (软件)设计基础
5. (软件)设计方法论
6. (软件)设计文档
7. 面向对象的(软件)设计
8. 结论
[b:4b927fde27]简介[/b:4b927fde27]
您是怎样开始一个新工程的?是不是跳到电脑前,打开您喜爱的 RAD 工具开始输入代码?有没有想过程式会执行些什么或系统是怎样操纵数据的?有没有想过要记下些东西来帮助提醒您或阐明您已研发的代码的逻辑实现?假如您对第一个问题答 " 不 " ,而其他问题答 " 是 " 的话,您能够跳过这篇文档。否则的话,请 好好读读 这篇文章。您应该有个计划、蓝图,并且在手边有个对您的问题解决方案的简明安排。 " 您必须知道您要去哪儿得到一切! " 让我们来看看研发一个能实现您所设计的功能的程式时,什么最棘手。
[b:4b927fde27](软件)设计是什么? [/b:4b927fde27]
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. "
" … 应用各种各样的技术和原理,并用他们足够周详的定义一个设备、一个程式或系统的物理实现的过程。 "
对任意的工程产品或系统,研发阶段绝对的第一步是确定将来所要构建的制造原型或实体表现的目标构思。这个步骤是由多方面的直觉和判断力来一起决定的。这些方面包括构建类似模型的经验、一组引领模型发展的原则、一套启动质量评价的标准、连同重复修改直至设计最后定型的过程本身。电脑软件设计和其他工程学科相比还处在幼年时期,仍在不断变化中,例如更新的方法、更好的算法分析、连同理解力的显著进化。软件设计的方法论的出现也只有三十年多一点,仍然缺乏深度、适应性和定量性质,通常更多的和经典工程设计学科相联系。尽管如此,现今的软件技术已存在、设计质量的标准也可使用、设计符号亦能够应用。带着这些意见,我们一起来看看什么有助于程式员们找到他们的软件涅盘 ( 天堂的意思  。
[b:4b927fde27](软件)设计过程 [/b:4b927fde27]
软件的设计是个将需求转变为软件陈述(表达)的过程。这种陈述给我们一个对软件的全局观点。系统通过逐步求精使得设计陈述逐渐接近源代码。这里有两个基本步骤;第一步是 初步设计 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 的法则建议 由设计决定所刻划的模块特性应该对其余的模块不可见 。换句话说,模块应被设计和指定为包含在模块内部且其他模块不可访问的内容对其他模块来说是无需的。隐藏意味着有效的模块性能够通过定义一套单独的模块来实现,这些模块相互之间的通信仅仅包括实现软件功能的所必须的信息。将使用信息隐藏作为设计标准在测试或今后的维护期间需要修改系统时带来了最大的好处。
[b:4b927fde27](软件)设计方法论 [/b:4b927fde27]
让我们来遍历设计过程中用以促成模块化设计的四个区域: 模块 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 在数据、程式结构、和陈述周详算法的说明都已使用类似英语的自然语言来呈现后,再确定程式设计。使用自然语言来陈述的原因是当研发小组的绝大多数成员使用自然语言来交流的话,那么小组外的一个新手在不经学习的情况下会更容易理解这些说明。这里有个问题:程式设计必须毫无歧义的来周详说明程式,但我们都知道不含糊的自然语言也就不自然了。
[b:4b927fde27](软件)设计文档 [/b:4b927fde27]
在任何系统中,研发文档都是有价值的东西。现在已有许多不同的经过发展的文档计划可供您在创建系统时候进行选择。其中相当不错的一种模型就是所谓的设计规范 (译者注:此处原有的超链接已失效,所以无法得到其原始的模板。但 CKER 更有一套被称作的 APM 的文档模板似乎不错。以后也许会翻给大家来看看 ……^_^ ) 。 当您察看此文档的大纲的时候 , 请注意各级别的周详内容。
第一部分展示了源自于系统说明和其他定义文档的设计成果的总体范围。第二部分展示的是涉及支持文档的周详说明。第三部分的内容又称作设计描述,在初步设计阶段完成。第四、五部分的内容将初步设计阶段的内容发展至周详设计阶段。第六部分展示了确保以下两条原则的交叉参考矩阵:
1. 用软件设计满足任何的需求。
2. 指出实现特定需求的关键模块。
第七部分在研发测试程式(步骤)的第一步对系统的功能性和正确性进行测试是必要的。假如在研发设计规范的同时已并行研发了周详的测试程式规范的话,本部分能够删除。第八部分周详说明了将系统打包传送至用户站点的考虑和需要。在文档剩下的第九、十部分中包括了算法描述、选择程式、列表数据、流程图、伪代码、数据流图表、连同任何在设计规范研发时所用到的相关信息都能够放在此处。
[b:4b927fde27]面向对象的(软件)设计 [/b:4b927fde27]
到现在为止我们所周详说明的一切都是如今在 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)<让您的代码保持短小简单> 。
[b:4b927fde27]设计时的参考良书: [/b:4b927fde27]
"Software Engineering, A practitioner’s approach 3rd edition", by Roger S. Pressman."
"Object-Oriented Design", by Peter Coad and Edward Yourdon"
| 无双 回复于:2003-05-22 18:52:41
| 现在正在看设计模式
发现原来一个大程式设计时原来是分成多个模式的
大有收获
|
|
还没有关于此文章的相关评论!