《2014-软件工程6》由会员分享，可在线阅读，更多相关《2014-软件工程6（90页珍藏版）》请在金锄头文库上搜索。
1、1/360Chapter 6 软件设计方法软件设计方法 6.1 设计的概念 6.2 分治 6.3 抽象 6.4 内聚和耦合 6.5 复用 6.6 设计描述方法 6.7 人-机界面的设计 6.8 相关文档规范2/3606.1 设计的概念设计的概念(1/7) 设计的总体原则 不应陷入片面性 追踪分析模型 选择合适的技术 适度分解 可集成 提高抽象层次 可复用 可维护和可扩展的 有韧性 一致性 交互界面应该友好 设计评审3/3606.1 设计的概念设计的概念(2/7) 软件构架 UML： 指系统的组织结构，它可以递归解构为通过接 口交互的部件、连接部件的关系以及组装部件 的一些限制条件，通过接口交互
2、的部件有类、 构件和子系统。 IEEE： 系统在其环境中的最高层概念4/3606.1 设计的概念设计的概念(3/7) 软件构架 Mary Shaw和David Garlan 关于构成系统的元素、这些元素之间的交互、 元素和元素之间的组成模式以及作用在这些组 成模式上的约束等方面的描述 Rational Unified Process 指通过接口交互的重要构件的组织或结构，这 些构件又由一些更小的构件和接口组成。5/3606.1 设计的概念设计的概念(4/7) 软件构架 反映系统整体的组织结构和基本特征 软件的层次结构 模块相互作用的方式 全局的、重要的数据变量和数据结构 数据库的逻辑结构 接口
3、6/3606.1 设计的概念设计的概念(5/7) 软件构架 对复杂的系统进行抽象，为系统设计规划蓝 图，是关于系统构造及系统各构件工作机制 的相对精简、却能清晰反映核心问题的模 型，体现了项目早期的设计决策，可以作为 相关涉众对系统理解和交流以及进行项目管 理的基础，能够帮助开发人员进一步细化和 实施系统 一个好的软件构架已经成为完成高质量软件 的重要保证，它在软件开发中起到核心作用7/3606.1 设计的概念设计的概念(6/7) 软件体系结构和其它开发任务的关系8/3606.1 设计的概念设计的概念(7/7) 详细设计 在软件构架的基础上进一步确定如何实现目 标系统，具体包括系统的模块（如类
4、及其方 法）逻辑的详细设计、系统数据结构的设 计、系统数据库结构的设计、系统人-机接 口的设计等9/3606.2 分治分治(1/6) 分治思想 架构设计-将系统分解为一组子系统或模 块，以及子系统或模块之间的接口。 详细设计-子系统或模块被再次细分为子 模块 传统软件工程中的过程、函数 面向对象软件工程中的包、类、接口和方法等10/3606.2 分治分治(2/6) 分治的优点 1)缩小问题空间，减少问题复杂度和工作量C(p1)C(p2) E(p1) E (p2) 或 C(p1) E (p2) C(p1+ p2) C(p1)+C(p2) E(p1+ p2) E(p1 ; p2) E(p1 ; p
5、2)=E(p1)+ E(p2) E(p1+ p2) E(p1)+ E(p2)11/3606.2 分治分治(3/6) 分治的优点 2)便于并发执行，缩短开发周期 3)适合团队协作，降低了实施难度 4)预防了开发中的多米诺骨牌效应 5)容易产生可复用部件12/3606.2 分治分治(4/6) 分治要考虑的问题 1)分治是否可以无限分解，是否越细越好13/3606.2 分治分治(5/6) 分治要考虑的问题 2)从技术的角度讲，如何分治？ 程序设计方法 部件重用 可理解性 独立性 有界性14/3606.2 分治分治(6/6) 分治要考虑的问题 3)如何将任务分解到不同的时间域上？ 需求的优先级 基础部
6、件 项目风险 任务执行的难易程度15/3606.3 抽象抽象(1/7) 抽象思想 为了降低复杂度，应该隐藏细节或推迟考虑 细节 抽象的优点 有利于认识事物的普遍特征和基本原理 帮助设计人员制定出模块的“框架” 有利于软件的复用 提高系统的的可扩展性16/3606.3 抽象抽象(2/7) 基于抽象的设计原则 1)里氏替换原则(Liskov Principle) 子类可以替换父类，可以出现在父类能出现的 任何地方 如果对于每一个类型为T1的对象o1，都有类型 为T2的对象o2，使得以T1定义的所有程序P在所 有的对象o1都替换成 o2时，程序P的行为没有 变化，那么类型T2是类型T1的子类型。17
7、/3606.3 抽象抽象(3/7) 基于抽象的设计原则 2)开闭原则(Open-Closed Principle) 即一个软件实体应当对扩展开放，对修改关闭18/3606.3 抽象抽象(4/7) 基于抽象的设计原则 3) 依赖倒转原则(Dependence Inversion Priciple) 要依赖于抽象，不要依赖于具体类19/3606.3 抽象抽象(5/7) 传统软件工程中的抽象 信息隐蔽 指一个模块内的数据和模块的实现细节对于该 模块的客户即调用者模块有不可见的性质 数据局部化 缺点 仅对模块细节的封装，没有继承的概念，虽然 可以“到处复用”，却也需要“到处修改”20/3606.3 抽
8、象抽象(6/7) 面向对象软件工程中的抽象 继承传统，发展深化 抽象类21/3606.3 抽象抽象(7/7) 面向对象软件工程中的抽象 接口22/3606.4 内聚和耦合内聚和耦合(1/18) 内聚 是一个模块内部各部件之间联系紧密程度的 度量 强调分解时将相关的内容放到一起 一个模块内的各个部件联系越紧越好 耦合 是模块间相互联系强弱的度量 耦合的强弱取决于模块间传递数据的方式、 接口复杂情况以及传递数据的类型 各模块之间的耦合越松散越好23/3606.4.1 内聚内聚(1/10) 内聚的分类 1)功能内聚（Functional Cohesion） 所有部件处理同一组数据，共同完成单一的功能
9、 易于理解、易于诊断、易于维护、易于替换、易 于复用24/3606.4.1 内聚内聚(2/10) 内聚的分类 2)顺序内聚（Sequential Cohesion） 各部件之间既有数据联系又有控制联系 较为理想25/3606.4.1 内聚内聚(3/10) 内聚的分类 3)通信内聚（Communicational Cohesion） 所有的部件都访问同一组数据，各部件之间只 有数据关系，没有控制关系 较为理想26/3606.4.1 内聚内聚(4/10) 内聚的分类 4)过程内聚（Procedural Cohesion） 各部件之间只有控制联系，而没有数据联系 较弱的内聚27/3606.4.1 内
10、聚内聚(5/10) 内聚的分类 5)时间内聚（Temporal Cohesion） 所有部件之间既无数据联系，也无控制联系， 但是部件之间具有时间关系，即把在执行过程 中同一阶段内完成执行任务的部件放到一起， 而排除其它部件 内聚更弱28/3606.4.1 内聚内聚(6/10) 内聚的分类 6)实用程序内聚（Utility Cohesion） 部件常常是一些相关的、可重用的实用程序 内聚很弱29/3606.4.1 内聚内聚(7/10) 内聚的分类 7)偶然内聚（Coincidental Cohesion） 模块内部的各部件之间没有任何关系 最不好的一种内聚类型30/3606.4.1 内聚内聚(
11、8/10) 内聚的分类 8)层内聚（Layer Cohesion） 将相关服务的功能放到一起，成为一层，而将 其它内容排出在外 替换低层时可以用等价层（实现原层所有的 API）而不必修改高层，替换高层模块对低层 模块没有影响（低层服务不访问高层服务） 层内聚被广泛地应用在软件的分层架构上31/3606.4.1 内聚内聚(9/10) 内聚的分类 8)层内聚32/3606.4.1 内聚内聚(10/10) 相互嵌套的内聚模块33/3606.4.2 耦合耦合(1/6) 解耦的原因 牵一发而动全身 很难快速地理解紧耦合的模块 独立性较差34/3606.4.2 耦合耦合(2/6) 耦合的分类 1)内容耦合
12、（Content coupling） 一个模块直接进入另一个模块中存取其数据或 使用其服务 最不好的一种耦合35/3606.4.2 耦合耦合(3/6) 耦合的分类 2)公共耦合（Common coupling） 两个模块间通过一个公共环境进行数据交换 较差的耦合，应该避免使用36/3606.4.2 耦合耦合(4/6) 耦合的分类 3)外部耦合（External coupling） 模块对外部系统（如软件操作系统、数据库、硬 件设备，以及可复用的组件库等）有依赖关系 有时无法避免，应该尽量减少 4)控制耦合（Control coupling） 两个模块之间通过接口的参数表交换开关数据， 旨在控制
13、另一个模块的执行逻辑 较差37/3606.4.2 耦合耦合(5/6) 耦合的分类 5)印记耦合（Stamp coupling） Pressman：指两个模块之间通过参数交换方式 产生耦合，并且交换的是数据结构而不是数据 元素 Timothy C. Lethbridge：当应用程序的类被声明为 方法参数类型时，就会产生印记耦合 允许使用38/3606.4.2 耦合耦合(6/6) 耦合的分类 6)数据耦合（Data coupling） 两个模块之间通过接口的参数表交换信息数 据，并且这些信息数据的类型是基本数据类型 需要传递的参数较少时，数据耦合较好 需要传递的参数较多时，印记耦合要更好39/36
14、06.4 内聚和耦合内聚和耦合(18/18) 内聚谱系和耦合谱系40/360复用的概念复用技术6.5 复用复用(1/20) 提高软件生产率的办法 改进过程 改善需求分析方法 改进设计方法 改进工具 然而 复用最有效率的方法之一案例案例41/360优势展望优势展望 软件行业相关资料（摘录） 软件复用技术： 软件产品开发周期缩短为原来的1/24/5 软件产品的缺陷密度减少至原来的 10%50% 软件开发费用能减少15%75% 维护费用也大大降低42/360 软件复用程度的相关数据 美国电报电信公司开发的电信支持系统起软 件复用率达到40%92% 摩托罗拉公司在为编译器编写测试包时，复 用率高达85
15、% 1984年惠普HP公司就开发了可复用的组 件；1987年建立了自己的软件复用库；软 件复用率达到10%50 1991年的统计报告显示：日本软件公司其 软件复用率达到50%43/360软件工程的一个新的发展方向软件工程的一个新的发展方向-复用复用 应用系统的开发不再采用一切从“零”开 始的模式，可以充分利用过去应用系统 开发中积累的知识和经验 优点： 提升软件开发速度和效率 缩短开发周期 提升软件产品质量 降低开发成本44/3606.5.1 复用的概念复用的概念 (1/4) 复用的定义 Biggerstaff和Ritcher: 在新的开发项目中使用以前已获得的概念和对象概念和对象概念和对象概念和对象 Tracz: 特别为复用目的而设计的软件的过程过程过程过程 Freeman: 是一种通过使用以前开发工作的某些东西东西东西东西来生产 （或帮助生产）一个系统的过程过程过程过程，其关键问题是 复用什么、什么是导致成功复用的过程45/360
