S E Y Chapter 3 软件设计基础.

Presentation on theme: "S E Y Chapter 3 软件设计基础."— Presentation transcript:

1 S E Y Chapter 3 软件设计基础

2 S E Y 软件设计概述 1 软件体系结构设计 2 模块化设计 3 界面设计 4 软件设计评审 5

3 软件设计基础 需求工程阶段，回答“软件必须做什么”这个问题。 软件设计阶段，回答“软件怎么实现”的问题
软件设计的目标就是要构造一个高内聚、高可靠性、高维护性和高效的软件模型，为提高软件质量提供坚实的基础。

4 软件设计与软件需求 软件设计的依据是需求规格说明和数据规格说明。它根据描述的信息域需求，包括功能需求、性能需求、领域需求、数据需求等的定义，进行数据设计、体系结构设计、界面设计和过程设计，并通过这四个层面的设计，将现实世界的具体问题（需求）转换为信息设计的逻辑问题（设计方案）。

5 软件设计与软件需求 实体关系模型 数据 流图 状态转换图 控制规格说明 加工规格说明 数据对象说明 系统设计 系统需求 界面设计
体系结构设计 数据设计 数据字典 过程设计

6 软件设计与软件需求 开发阶段信息流描述了软件设计从软件需求到软件编码，起到承上启下的作用。

7 软件设计的任务 设计任务：将需求阶段获得的需求说明（模型）转换为计算机中可实现的系统。 设计阶段 概要设计 详细设计 体系结构设计 设计内容
界面设计 数据设计 过程设计 概要设计 详细设计 设计内容 设计阶段 设计任务：将需求阶段获得的需求说明（模型）转换为计算机中可实现的系统。

8 软件设计的任务

9 软件设计的任务—概要设计 概要设计也称总体设计，主要任务是基于数据流图和数据字典，确定系统整体软件结构，划分软件体系结构的各子系统或模块，确定它们之间的关系。

10 软件设计的任务—概要设计 体系结构设计：确定各子系统模块间的数据传递、调用关系。在结构化设计中，体现为模块划分，并通过数据流图和数据字典进行转换。在面向对象设计中，体现为主题划分，主要确定类及类间关系。

11 软件设计的任务—概要设计 界面设计：包括与系统交互的人机界面设计，以及模块间、系统与外部系统的接口关系。在结构化设计中，根据数据流条目，定义模块接口、全局的数据结构。在面向对象设计中，定义关联类、接口类、边界类等，既满足人机交互界面数据的统一，也完成类间数据的传递。

12 软件设计的任务—概要设计 数据设计：包括数据库、数据文件和全局数据结构的定义。在结构化设计中，通过需求阶段的实体关系图、数据字典建立数据模型。在面向对象设计中，通过类的抽象与实例化，以及类的永久存储设计，完成数据设计过程。

13 软件设计的任务—详细设计 详细设计是在概要设计的基础上，具体实现各部分的细节，直至系统的所有内容都有足够详细的过程描述。
过程设计包括确定软件各模块的具体实现过程及局部数据结构。在结构化设计中，模块独立性约束了数据结构与算法相分离的情况，使得两者在设计时务必有局部性，减少外部对两者的影响。在面向对象设计中，类的封装较好地体现了算法和数据结构的内部性。类的继承性提供了多个类（类家族）共同实现过程设计的机制。

14 软件设计的任务 修改 概要设计 需求规格说明 体系结构 数据设计、界面设计 详细设计 过程设计 复审 设计规格说明

15 软件设计的原则 分而治之 软件设计的原则 模块化是在软件设计上实现分而治之思想的技术手段。在结构化设计中，模块可以是函数、过程、甚至是代码片段。在面向对象设计中，类是模块的主要形式。

16 软件设计的原则 分而治之 重用设计模式 软件设计的原则
重用是指同一事物不做修改或稍作修改就能多次使用的机制。在软件设计阶段，重用的内容是软件设计模式。通过重用设计模式，不仅使得软件设计质量得到保证，而且把资源集中于设计的新流程、新方法中，并在设计时更进一步考虑新流程、新方法在将来的重用。

17 软件设计的原则 分而治之 重用设计模式 软件设计的原则 可跟踪性
确定软件各部分间的关系，各模块间的相互调用或控制关系，以便在需要修改模块时能掌握与修改模块有关的其他部分，并正确追溯问题根源。

18 软件设计的原则 分而治之 重用设计模式 灵活性 软件设计的原则 可跟踪性
设计具有易修改性。发生修改的原因：用户需求发生变更；设计存在缺陷；设计需要进行优化；设计利用重用。软件设计灵活性主要通过系统描述问题的抽象来体现。

19 软件设计的原则 重用设计模式 分而治之 灵活性 软件设计的原则 可跟踪性 一致性 界面视图的一致性保证了用户体验了对系统的忠诚度

20 S E Y 软件设计概述 1 软件体系结构设计 2 模块化设计 3 界面设计 4 软件设计评审 5

21 软件体系结构设计 软件体系结构为系统设计提供了一套关于数据、行为、结构的指导性框架，该框架提供了描述系统数据、数据间关系的静态特征，也对数据的操作、系统控制和通信等活动提供了具有动态特征的描述过程。 系统的静态特征体现了系统的组织结构，系统的动态特征体现系统操作流程的拓扑结构，共同构成设计决策的基本指导方针。

22 软件体系结构设计 体系结构设计是软件设计的早期活动，它的作用集中在两点： 提供软件设计师能够预期的体系结构描述。
数据结构、文件组织、文件结构体现了软件设计的早期抉择。

23 以数据为中心的数据仓库模型 数据仓库模型是一种集中式模型。数据仓库模型是能独立提供数据服务的封闭式数据环境。它不单独集成到某一应用系统中，而是为具体的应用系统提供服务。这些服务既有通用的公共服务，也有专门设计的领域服务。

24 以数据为中心的数据仓库模型

25 以数据为中心的数据仓库模型 优点： 数据统一存储和管理，确保了数据的实时性。 数据仓库对数据复杂性的统一封装，有利于数据共享。
采用黑板模型，与某类数据有关的应用系统能及时获取数据。 采用数据订阅推送模型，应用系统在有数据更新时，能动获得数据，而不用采取询问方式，这就提高了数据管理效率。 各应用系统间仅通过数据仓库完成数据交换，在功能上没有关联，增加、删除应用系统及其部分功能，将不会影响其它应用系统的正确运行。

26 以数据为中心的数据仓库模型 缺点： 为了对数据仓库数据进行操作，不同应用系统的数据视图必须统一，否则难易达到数据共享的目的，但这不可避免的会降低各应用系统的效率。 如果应用系统的数据结构发生改变，就需要单独设计数据适配器，以实现新的结构与数据仓库在数据上的匹配。这不仅增加应用系统设计的复杂度，而且有时甚至是难以完成这样的数据匹配。

27 以数据为中心的数据仓库模型 缺点： 随着网络技术的发展，数据共享带来的访问控制的复杂性、安全性、效率、备份、存储、恢复策略等一系列问题，影响了仓库模型的有效利用。

28 客户端/服务器模式的分布式结构 集中式数据仓库模型在带来数据一致性访问优势的同时，也造成网络环境下难以分布应用的缺陷。
分布式结构模型是充分利用、整合网络中计算机各自的计算能力，从而提高整个网络系统运行的能力和效率。

29 客户端/服务器模式的分布式结构 C/S结构是一种分布式模型，采用发请求、得结果的模式：
客户机：向服务器发出请求(数据请求、网页请求、文件传输请求等等)， 服务器 ：响应请求，进行相应的操作，将结果回传给客户机，客户机再将格式化后的结果呈现给用户。

30 客户端/服务器模式的分布式结构 C/S结构的应用都由三个相对独立的逻辑部分组成：
允许客户端与服务器端的软硬件配置不同，体现了分布式模型的灵活性。 用户界面视图（客户端） 系统逻辑功能（服务器端） 数据访问

31 客户端/服务器模式的分布式结构 目前应用比较多的C/S模式的分布式结构： “三层网络设计模式”，用两层分布式设计映射三层逻辑。 用户界面
逻辑应用 数据访问 客户端逻辑应用 服务器端逻辑应用 网络

32 客户端/服务器模式的分布式结构 针对多层逻辑应用提出了多层分布式设计模型 第一层 客户端 网页请求 网络 数据操纵请求 逻辑服务请求
服务器端 第三层 第二层 第三层

33 分布式结构设计的特点 共享：实现了数据共享，云计算的提出还能进一步实现计算共享。 异构型：客户端/服务器允许软硬件配置不同。
开放性：只要符合互联网协议，任何计算机、局域网、智能设备和物品等都可连入互联网。

34 分布式结构设计的特点 易修改性：由于用户界面、系统逻辑和数据访问分布的不同，各部分具有较强独立性，易于系统的修改和维护。
透明性：分布式结构中仅需要知道服务器的服务位置，而对后端的逻辑实现、数据存储、数据访问等不必清楚其架构和访问方式。

35 分布式结构设计的不足 复杂性：面对网络通信、服务器端分层等问题的管理，控制结构复杂。
安全性：身份验证困难。客户端的访问是问答模式，对客户端的响应由服务器提供服务，因而难以验证客户端真是身份。给病毒、流氓软件等不良软件带来了可乘之机。 运行状态难以确定：特别是网络通信出现故障时，提交的信息是否有效，是否得到正确相应，都困扰着分布式模型的发展和应用。

36 层次模型 层次模型——又称为分层模型，通常用于建立子系统的接口模型。
层次模型将系统划分为若干层次，每层提供一组服务，每层定义一个抽象机，每个层次提供单向服务，如底层向顶层提供服务。

37 层次模型 优点：支持增量式开发。 缺点：系统构成，性能保证较困难。 应用层协议 表示层协议 会晤层协议 传输层协议 物 理 介 质 应用层
物 理 介 质 应用层 表示层 会晤层 传输层 网络层 数据链路层 物理层 中继系统 中继系统 主机系统 优点：支持增量式开发。 缺点：系统构成，性能保证较困难。

38 S E Y 软件设计概述 1 软件体系结构设计 2 模块化设计 3 界面设计 4 软件设计评审 5

39 模块化设计 模块是程序语句的集合，它拥有独立的命名，明确的输入、输出和范围。程序设计中的函数、过程、类、库等都可作为模块。

40 模块化设计—软件模块化与分解 对于整个软件系统来说，设计人员不是把它作为一个问题来整体解决，而是把它的全部功能按照一定的原则规划分成若干个模块，如果某个模块仍难以理解或实现，则把它再进行划分，得到更小、功能更简单的模块，如此往复，直至所有模块都可解，这个过程就是软件模块化设计。

41 模块化设计—软件模块化与分解 P1 P2 分解 模块设计 P3 P4

42 模块化设计—软件模块化与分解 将问题(P1+P2)分解为P1,P2
设函数C(x)定义问题x的复杂程度，函数E(x)确定解决问题x需要的工作量。对问题P1和P2，如： C(P1) > C(P2) 显然： E(P1) > E(P2) 有规律：C(P1+P2) >= C(P1)+C(P2) E(P1+P2) >= E(P1)+E(P2) ＂各个击破＂

43 模块化设计—软件模块化与分解 如果模块分解过程无限进行下去，不仅问题的复杂度不会减少，反而还会增加（因为会增加接口定义和它们之间调用关系的设计和实现的工作量）。 M区间是一个合适的模块分解范围，它同时兼顾了对问题的分解和模块间设计与实现的工作量。

44 模块化设计—抽象 抽象是指对软件设计不同层次的理解，它与分解是解决问题的两个方面。分解是对问题细节的表述，抽象则忽略问题的细节，抓住问题的本质。 分为：“实体对象抽象”、“接口抽象”和“设计模式抽象”三类。

45 模块化设计—实体对象抽象 实体对象抽象也称为数据抽象，它是对需求陈述中实体的归纳。
归纳包括两种形式，一种是对陈述中实体的抽象。如“简历自动获取和查询系统”中，有pdf、doc、txt等不同格式的文件，这时抽。象出“简历文件”来统一简历文本的描述；另一种形式是分析总结出陈述中的新实体。如当从简历文件中获取信息后，可以设计出“数据操作”对象来完成对简历信息的有效检查，并迅如数据库文件中。

46 模块化设计—接口抽象 接口抽象的目的是通过统一的接口，设计不同的实现过程。这样不仅易于理解和使用，也利于系统功能的扩展。
典型的接口抽象是开放式数据库连接（ODBC），它通过一组定义的统一接口，实现了不同数据库文件对增加、删除、修改、查询等的统一操作，简化了业务逻辑与数据库的接口，目的是让软件设计人员能将更多的精力投入到实现系统的业务逻辑上。

47 模块化设计—设计模式抽象 设计模式的抽象即是设计模型，它是对有相同数据组织、行为、结构的系统的指导性框架。
设计模式为不同模型、不同业务逻辑提供统一的软件组织结构提供了可能。

48 模块化设计—信息隐藏 信息隐藏是把数据结构与实现过程放在一起，使得相关内容彼此靠近，对外提供相对完整、独立的功能，对隐藏信息的访问只能通过接口进行操作。 信息隐藏提高了软件的可修改性和重用性，因为修改涉及的是模块内部，避免与外部的交互，这样使得修改的影响局限于一个较小的范围之内。

49 模块化设计—信息隐藏 例：C语言与C++语言编写的关于栈的定义 P73—P74

50 模块化设计—模块独立性 模块独立性是指软件系统中划分的模块完成一个相对独立的功能，而与其它模块的关联尽量只发生在接口上。模块独立性是由模块化、分解与抽象、信息隐藏等要素共同构成。 独立性是良好设计的关键，是衡量软件质量的重要指标之一。

51 模块化设计—模块独立性 模块独立性由内聚性和耦合性两个指标来评价。它们分别描述模块内部和模块间的紧密程度。木块内关联度越高，模块间的相关性越低，模块独立性就越强

52 模块化设计—模块独立性 低 高 内聚性 偶然内聚 逻辑内聚 时间内聚 过程内聚 通信内聚 顺序内聚 功能内聚 低 高 模块独立性

53 模块化设计—模块独立性 低 高 内聚性 非直接耦合 数据耦合 特征耦合 控制耦合 公共耦合 内容耦合 低 高 模块独立性

54 启发式规则 模块化设计的指导思想是分解、抽象、求精、信息隐藏和模块独立性。
设计人员根据长期的实践经验，提出了一些软件模块化设计的启发式规则。在多数场合下，启发式规则能给软件工程师有益的启示，帮助他们找到改进软件设计、提高软件质量途径。

55 启发式规则—改进软件结构，提高模块独立性
通过对软件整体结构模块进行划分后，进行分解和合并的优化过程，提高模块内聚性。但同时也要防止出现模块划分过细，模块功能过于简单而造成模块数量过多的情况。

56 启发式规则—改进软件结构，提高模块独立性
对已分解模块采用抽取和合并方式进行结构化。 A B C D E F A B C A BCD EF

57 启发式规则—模块规模适中 模块数目不宜太多，否则会则会增加模块间数据传递和相互调用的复杂度。
特别是当模块仅调用一两个模块时，可以合并这些模块，这样能最大程度保证模块独立性，且降低模块数量。

58 启发式规则—宽度、深度、扇出度、扇入度适中
宽度是指软件结构中同一层次上模块数目的最大值。宽度越大，软件复杂度就越高。 深度是指软件结构中模块能控制的最深得层数。深度越大，模块分解也就越细，软件复杂度就越高 扇出度是指软件结构中同一模块能直接调用的其他模块数目。模块的扇出度越大，说明模块的控制结构越复杂。 扇入度是指软件结构中同一模块被直接调用的模块数目。扇入度越大，说明该模块被共享的次数越多，独立性越强。

59 启发式规则—模块的作用域 模块的作用域是指模块内定义的所有元素（如数据、变量等）各自的使用范围。
模块的控制域是指模块所能操作和调用的所有元素（如其他模块等）的集合。

60 启发式规则—模块的作用域 A 效果 C B 判断 D 效果 B

61 启发式规则—设计单入口、单出口的模块 设计单入口、单出口的模块，力争降低模块接口的复杂度。
对于模块出入口的设计，最易理解和维护的方式是，入口在模块的开始处，模块的末尾是出口。然而在实际设计中，由于有异常、错误处理等判断，存在模块出入口位置发生改变的情况。

62 启发式规则—设计单入口、单出口的模块 设计单入口、单出口的模块，力争降低模块接口的复杂度。
对于模块出入口的设计，最易理解和维护的方式是，入口在模块的开始处，模块的末尾是出口。然而在实际设计中，由于有异常、错误处理等判断，存在模块出入口位置发生改变的情况。

63 启发式规则—设计单入口、单出口的模块 好的模块命名，能正确反应模块功能，减轻调用者的记忆、理解和调用负担。反之不仅不利于记忆和理解，甚至会带来错误的使用。模块的参数直接关系模块调用的易理解性和易用性。 通常情况下，模块接口的参数越少，理解和使用就越简单。但在实际设计中，仍要灵活掌握这一原则。

64 启发式规则—设计单入口、单出口的模块 求一元二次方程解的模块接口定义：
QUAT_ROOT（ARGUS，X） // ARGUS：方程系数数 组，X：方程解的数组 QUAT_ROOT（A，B，C，X1，X2） // A，B，C：方程的三个参数；X1（指针）， X2（指针）表示方程的两个解

65 启发式规则—模块功能可以预测 在任何环境和情况下，只要输入模块的数据不变，模块的预期结果就不会改变。

66 S E Y 软件设计概述 1 软件体系结构设计 2 模块化设计 3 界面设计 4 软件设计评审 5

67 界面设计 软件设计中的系统结构设计、数据设计和过程设计是关于系统内部的任务，而界面设计是人与系统、系统和外部系统间的交互过程。
界面是用户和系统之间进行数据接收、数据变换、数据展示的平台，它实现的是系统内部信息表示和用户数据显示之间的转换。界面设计时计算机技术与心理学、认知科学、设计艺术以及人机工程的交叉领域。

68 界面设计的任务 界面设计涉及需求分析中的数据源、用户操作习惯、信息反馈等问题。界面设计的任务主要包括用户特性研究、用户工作分析、界面任务分析、界面类型确定和界面原型评估。

69 界面设计的任务 用户特征分析是为了能够详细了解用户对计算机的认识和应用程度，以便预测用户对不同的软件设计的接受度。因此确定用户类型是首要人物。用户类型通常分为外行型、初学型、熟练型和专家型 用户工作分析主要是对系统内部功能进行自顶向下的分解。但它所分解的任务是与人、外部系统、数据文件相关的活动，设计的内容包括数据的变换和传递。

70 界面设计的任务 根据用户工作分析的数据操作，设计用户界面以完成用户对系统的控制和数据的接收、转换和显示。具体包括软件封面设计、软件界面框架设计、按钮设计、菜单设计、图标设计、滚动条设计、状态栏设计、鼠标和键盘按键设计、软件安装向导设计、包装及商品化设计等。 选择界面类型时，用考虑界面操作的难易程度、界面学习的难易程度、界面开发的难易程度、界面对系统的控制能力、界面对系统反馈的及时程度等综合因素。 对于界面型设计的功效、可用性、用户体验等进行评估、修改和确认，使得界面设计在外观、功能、操作反馈、数据处理过程展示等各方面都符合用户要求，符合市场需求。

71 界面设计的原则 系统所有界面操作的统一 提供系统运行过程中必要的反馈信息 软件设计的原则 提供快捷方式和滚回操作

72 网页界面设计的原则 提供网页向导 软件设计的原则 KISS原则 界面设计的个性化

73 界面设计的黄金原则 置用户于控制之下 软件设计的原则 减少用户的记忆负担 保持界面一致

74 界面设计的特性 简易性 特性 帮助性 容错性 灵活性 个性化

75 作业 P62 12题

76 S E Y THANK YOU!