• 1. 第 5 讲 需求分析建模
  • 2. 需求分析建模抽象与模型 需求分析建模的过程 需求分析建模的方法 结构化分析 面向对象分析 Jackson分析 结构化分析 数据建模 功能建模和信息流 行为建模
  • 3. 抽象 (Abstract)计算中抽象的本质和使用。 在处理复杂事务、构造系统、隐藏细节和获取重复模式方面使用抽象,通过对不同层次的细节和指标的抽象,能够表达一个实体和系统。 源于实验科学,主要要素是数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析。 在为可能的算法、数据结构和系统结构等构造模型时使用抽象。 抽象的结果是概念符号模型。
  • 4. 模型 (model)模型是对现实世界某些重要方面的抽象表示。 模型是一种抽象,从某个视点、在某种抽象层次上详细说明被建模的系统。 有时我们使用术语“抽象”来表示模型,因为我们从现实世界中抽象出对我们特别有用的东西。 分类 具体模型:直观模型、物理模型等; 抽象模型:思维模型、符号模型、数学模型等。
  • 5. 系统包含一组模型,每个参与软件系统 开发的人员都需要有一个独特的系统视角。系统构架工程师项目经理系统分析员设计人员测试人员用户
  • 6. 1 通过对现实环境的调查,获得当前系统的物理模型。 学 生学 生购 书 申 请购书 单发 票领 书 单书信北107 张教务科信北206 王会计室信北206 李出纳员(实南) 赵教材科学生购买教材的实际处理流程:当前系统物理模型需求分析的过程
  • 7. 需求分析的过程2 去掉具体模型中的非本质因素: 抽取现实系统的实质,抽象出当前系统的逻辑模型。 学 生学 生购 书 申 请购书 单发 票领 书 单书审查 有效性开发票开领 书单发书学生购买教材的逻辑模型
  • 8. 需求分析的过程3 分析当前系统与目标系统的差别,建立目标系 统的逻辑模型 。学 生审查并 开发票购书单发票领书单开领 书单无效书单学 生计算机教材管理系统的逻辑模型
  • 9. 需求分析的过程4 对目标系统的逻辑模型进行细化、改进与优化 5 需求分析的验证
  • 10. 当前 系统目标 系统物理 模型逻辑 模型逻辑 模型物理 模型模型化抽象化具体化实例化怎 么 做做 什 么当前 系统目标 系统需 求 定 义需求分析的过程
  • 11. 逻辑模型和物理模型模型是对对象系统的形式化的特征抽象,概括性或近似地表示; 构造模型的过程是一个抽象、分析的过程。对象 系统模型 系统抽象(映射)模型应用模型构造的过程
  • 12. 逻辑模型 物理模型 (本质模型、概念模型) (实施模型、技术模型)现 行 系 统目 标 系 统描述重要的业务功能,无论系统是如何实施的。描述现实系统是如何在物理上实现的。描述新系统的主要业务功能和用户新的需求,无论系统应如何实施。描述新系统是如何实施的(包括技术)。
  • 13. 模型化或模型方法是通过抽象、概括和一般化,把研究的对象或问题转化为本质(关系或结构)相同的另一对象或问题,从而加以解决的方法。模型化方法要求所建立的模型能真实反映所研究对象的整体结构、关系或某一过程、某一局部、某一侧面的本质特征和变化规律。
  • 14. 模型的作用在建模过程中了解系统 通过抽象降低复杂性 有助于回忆所有的细节 有助于开发小组间的交流 有助于与用户的交流 为系统的维护提供文档
  • 15. 需求分析建模方法按照信息的流向、结构、和内容三个方面可以将现有的需求分析建模方法划分为: 面向信息流向:结构化分析方法 面向信息结构:Jackson分析方法 面向信息内容:面向对象分析方法 描述系统需求时可以从系统的功能、行为和信息三个方面进行,侧重点可以不一样。
  • 16. 计算机世界现实世界影射
  • 17. 传统的开发模型不能完全适应具体的应用领域开发 软件开发过程实际是:人通过抽象、归纳把客观系统变换到软件系统,并保证软件系统的解等价客观系统的解。 由于客观系统与软件系统差异很大,所以变换过程必须通过一个中间过渡系统。不同的软件开发模型采用不同的过度系统完成变换过程。客观系统客观系统的解软件系统软件系统的解变换解的等价
  • 18. 计算机世界现实世界结 构 化 开 发 方 法结构化 分析结构化 设计结构化 编程OOAOODOOP面 向 对 象 开 发 方 法
  • 19. 结构化分析方法 SA结构化分析(Structured Analysis,SA)是由Douglas Ross 提出的,由DeMarco进行推广的。 采用自顶向下、逐层进行功能分解的系统分析方法来定义系统的需求。 适用于分析大型的数据处理系统。 方法的特点:利用数据流图(Data Flow Diagram,DFD)来帮助理解问题,对问题进行分析。 一般工具:DFD、数据字典、结构化英语、判定表、判定树等。
  • 20. 结构化分析方法功能分析工具:DFD、DD、结构化英语、判定表和判定树。 行为分析工具:状态迁移图、Petri网等。 数据分析工具:ER图或者EER(扩展ER)图。 SA主要针对数据处理领域,因此,系统分析的侧重点在于功能分析和数据分析,而行为分析使用得较少。
  • 21. 结构化分析结构化分析遵循的三条基本原则: 分解 抽象 映射 三个主要目标: 描述用户需要 建立创建软件设计的基础 定义软件完成后可被确认的一组需求
  • 22. SA的结构E-R图状态变迁图(STD图)加工规约控制规约数据对 象规 约数据字典 (DD)数据流图 (DFD)
  • 23. 分析模型的构成元素数据字典(DD) 模型核心,包含了所有数据对象的描述的中心库。 E-R图(ERD) 表示数据对象以及相互的关系,用于数据建模。 数据流图(DFD) 指明数据在系统中移动时如何被变换; 描述对数据流进行变换的功能; DFD中每个功能的描述包含在加工规约(小说明)。 用于功能建模。 状态变迁图(STD) 指明作为外部事件的结果,系统将如何动作。用于行为建模。
  • 24. 数据建模最常用的表示概念性数据模型的方法,是实体联系方法(Entity-Relationship Approach) ER图描述现实世界中的实体,而不涉及这些实体在系统中的实现方法。
  • 25. E-R图元素⑴ Entities 例: , ,StudentInstructorClass 实体是客观世界中存在的且可相互区分的事务。实体可以是人也可以是物,可以是具体的事物也可以是抽象概念。例如,职工、学生、课程、教师等都是实体。
  • 26. E-R图元素 客观世界中的事物彼此间往往是有联系的,例如,教师与课程间存在“教”这种联系。⑵ Relations 例:Enrolled inTeach111NMN
  • 27. E-R图元素 属性是实体或联系所具有的性质。通常一个实体由若干个属性来刻画。 例如,“学生”实体有学号、姓名、性别、系、年级⑶ Attributes 例: ,NameI D#
  • 28. E-R图…………InstructorStudentEnrolled inTeachClassI D #I D #NameNameSexSexTitleInstructor IDClass IDGradeStudent IDClass IDCreditI D #Subject例:
  • 29. 客人入住客房状态客房服务服务类别姓名 地址 身份证号码 护照号码 电话 ……客房号 床位数 房间类别 价格1 ……住宿编号 住宿时间 支付方式 ……日期,客人数 状态(已预定/占用/维修中) ……日期,数量 ……名称,价格 ……数据建模实例:简单的酒店系统数据模型
  • 30. 变换输入信息信息流模型输出信息外部实体外部实体外部实体输入信息外部实体外部实体输出信息输出信息功能建模和信息流数据存储
  • 31. 1 数据流图数据流图说明(Yourdon表示): 表示外部实体,代表数据源和数据池。 表示加工,代表接收输入,经过变换,继而产生输出的处理过程。 表示数据流,代表数据的流向和路径。 表示数据存储,代表系统加工的数据所存储的地方。 外部实体变换数据存储
  • 32. 外部实体数据流过程(加工)数据存储条目查 询请求查询可用条目1客户目录产品条目库存条目可用条目查询结果目的地响应来源触发器动作DFD的Gane表示
  • 33. 1 数据流图数据流图(DFD,Data Flow Diagram)描述逻辑模型的图形工具,表示数据在系统内的变化。 DFD可以分层表示信息流和功能的细节,既提供了功能建模的机制,又提供了信息流建模的机制。 第0层的DFD也被称为基本系统模型或语境模型。 DFD没有提供显式的处理顺序,过程或顺序式隐含在DFD中的,显式的推迟到系统设计时。 不要混淆DFD和程序流程图!
  • 34. 人 事 部 门人事工资 管理系统会 计 部 门职工出缺勤报表职工出缺勤信息职工工资信息职工工资报表职 工职工基本信息职工工资单人事工资管理系统的顶层DFD(概图)范例
  • 35. 职工基本 信息管理 子系统1.02.0人事工资管理系统0层DFD范例职工出缺勤信息职工工资管理子系统3.0职工出缺 勤管理 子系统职工基本信息职工工资信息人 事 部 门会 计 部 门职 工职工出缺勤报表 职工出缺勤信息职工工资信息职工工资报表职工基本信息职工工资单
  • 36. 建立职工 出缺勤信息3.1人事工资管理系统1层DFD:加工3.0的分解图职工出缺勤信息3.2制作职工出缺勤信息 统计表职工基本信息职工 出缺勤报表 职工 出缺勤信息
  • 37. 分层DFD实例一个简单的考务处理系统功能描述: (1)对考生送来的报名单进行检查; (2)对合格的报名单编好准考证号后将准考证送给 考生,并将汇总后的考生名单送给阅卷站; (3)对阅卷站送来的成绩单进行检查,并根据考试中心制定的合格标准审定合格者; (4)制作考生通知单(含成绩及合格/不合格标志)送给考生; (5)按地区进行成绩分类统计和试题难度分析,产生统计分析表。
  • 38. 考 生考务 处理系统考 试 中 心阅卷站不合格报名单报名单准考证考生通知单成 绩 清 单合格标准错误成绩 清单考生名 单统计分析表顶层数据流图
  • 39. 登记 报名单报名单准考证1统计成绩2不合格 报名单考生通知单成统计分析表考生名册绩清单合 格 标 准考生名 单成绩清单错误0层数据流图
  • 40. 1层数据流图 (a)检查 报名单报名单准考证1.1编准考证号1.2不合格 报名单考生名册考生名单合格 报名单登记 考生1.3
  • 41. 一层数据流图 (b)检查 成绩清单2.1审定 合格者2.2考生名册正确 成绩清单制作 通知单2.3分析 统计成绩2.4分析 试题难度2.5试题得分清单考生 通知单难度 分析表合格 标准分类 统计表成绩清单错误 成绩清单经审定的 成绩清单
  • 42. 数据流图分解原则DFD可以用来表示一个系统或软件在任何层次上的抽象。 较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。 0层数据流图应当把系统或软件作为一个单一的功能来描述。 应当注意原始的输入和输出。 每个过程的每次细化一般控制在3-4个分过程。 所有圆圈和箭头应用有意义的名称标注。一个名称标注在 同一个DFD中只能出现一次。 每次细化时,细化部分的输入和输出必须保持一致,即保持信息流连续性,有时称为平衡。 一次最好只对一个圆圈细化。
  • 43. S2132.22.12.33.13.2 顶层 (不编号)0层1层
  • 44. 监控固件和 操作接口每个固件状态动作 警告机器人初始化控制操作命令部件状态缓冲器位置 命令开始/停止处理 机器人命令机器人命令文件操作 设置处理活动记录机器人动作位串数据流和控制流举例 (使用Ward和Mellor符号)
  • 45. 数据和控制模型的关系 DFD加工规约加工模型DFD控制规约控制模型数据输出数据条件数据输入控制输入控制输出加工 激活者
  • 46. SafeHomede控制面板与用户 交互SAFEHOMEARMED POWER01123456789*0#OFF ARAY STAYMAX TEST BYPASSINSTANT CODE CHIMEREADYpanicalarm check fireaway stay instant bypass not ready
  • 47. SafeHomede的第0层DFDSafeHomede 软件系统用户命令 和数据显示信息控制面板传感器传感器 状态警铃电话线警告类型电话号码 拨音控制面板显示
  • 48. SafeHomede的第1层DFD控制 面板与用户 交互控制 面板 显示密码电话号码拨音传感器状态显示信息配置请求用户命令 和数据配置 系统警 铃电 话 线传感器配置信息显示信息 和状态监控 传感器激活/不 激活系统传感器信息密码 处理警告类型检验id信息开始 停止状态信息
  • 49. 监控传感器的第2层DFD电话号码拨音传感器状态配置数据显示格式配置信息产生警告 信息拨号评估设置传感器信息读传感器警告类型传感器id类型传感器id 类型定位
  • 50. SafeHomede的第一层CFD控制 面板与用户 交互控制 面板 显示显示活动状态(完成、在处理中)配置 系统警 铃电 话 线传感器配置信息显示信息 和状态监控 传感器激活/不 激活系统警告 信号密码 处理传感器 事件警告 状态超时闪烁标志开/关切换
  • 51. 控制规格说明控制规格说明用两种不同的方法表示系统的行为。 状态转换图STD -- 顺序说明 过程启动表PAT -- 组合说明
  • 52. 过程规格说明过程规格说明描述所有流模型的过程,该过程是最后的细化层次上的过程。 包括解说词文本、用PDL描述的过程算法、数学方程、图或表。
  • 53. 行为建模采用动态分析方法,直观地分析系统的动作。 最常用的动态分析方法: 状态迁移图 STD STD通过描述状态以及导致系统改变状态的事件来表示系统的行为。 状态是任意可观察的行为模式,一个状态代表系统的一种行为模式。STD指明了系统如何在状态间移动。 时序图 Petri网
  • 54. 就绪t1t4t2t3等待运行状态事件运行就绪等待t1t2t3t4运行就绪就绪等待进程的状态迁移图和状态迁移表状态迁移图
  • 55. SafeHomede的状态变迁图读用户 输入超时监视系统 状态传感器 事件行为显示用户反馈与“用户交互”有关开关/切换与“监视&控制系统”有关显示活动状态与“用户交互”有关传感器事件与“显示信息&状态”有关与“监视&控制系统”有关传感器事件传感器事件与“监视&控制系统”有关传感器事件与“显示信息 &状态”有关闪烁与“显示信息&状态”有关
  • 56. 数据字典DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义,使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解。
  • 57. 数据字典的内容名称 数据项或控制项、数据存储或外部实体的主要名称。要求命名唯一性、一致性、“见名知义”。 别名(alias) 最早使用的另一个名称 何处用/如何用 使用数据或控制项的加工列表,以及如何使用。 内容描述 表示内容的符号。 附加信息 关于数据类型、预设值、限制或局限等信息。
  • 58. 操作符 含义描述 = 定义为 + 与(顺序结构) {...}n 重复n次(循环结构) 〔..|..〕 或(选择结构) 〔.. , .. 〕 ( ... ) 任选 m..n 界域 *...,* 注释符DD内容描述符号表示
  • 59. F1:航班信息文件={航空公司名称+航班号 +起点+终点+日期 +起飞时间+降落时间} 航空公司名称=2{字母}4 航班号=3{十进制数字}3 字母=“A”…“Z” 十进制数字=“0”…“9” 起点=终点=1{汉字}10 起飞时间=降落时间=时+分 时=“00”…“23”  分=“00”…“59” 日期=年+月+日 年=[2000|2001|2002|2004] 月=“01”…“12”  日=“01”…“31”
  • 60. 重复项:起点=终点=1{汉字}10 航空公司名称=2{字母}4 航班号=3{十进制数字}3 组合项:日期=年+月+日 起飞时间=降落时间=时+分 选择项:年=[2000|2001|2002|2004] 原数据项:字母=“A”…“Z” 十进制数字=“0”…“9” 时=“00”…“23”  分=“00”…“59” 月=“01”…“12”  日=“01”…“31”
  • 61. 数据流条目给出DFD中某个数据流的定义, 通常包括: 数据流标识 数据流来源 数据流去向 数据流的数据组成 流动属性描述:频率、数据量
  • 62. 购 书 单发票领书单审查并 开发票开领 书单无效书单学生12各班学生 用 书 表举例:学生教材存量表
  • 63. 数据流条目说明举例数据流名:发票 别名: 无 简述: 学生购书时填写的项目 来源: 学生 去向: 加工1“审查并开发票” 组成: (学号)+姓名+{书号+数量} 数据流量:1000次/周 高峰值:开学期间1000次/天
  • 64. 数据存储条目(数据文件词条)对某个文件的定义,包括: 文件名 描述 数据结构 数据存储方式 关键码 存取频率和数据量 安全性要求
  • 65. 数据存储条目说明举例文件名:库存记录 别名: 无 简述:存放库存所有可供货物的信息 组成:货物名称+编号+生产厂家 +单价+库存量 组织方式:索引文件,以货物编号为 关键字 查询要求:要求能够立即查询
  • 66. 数据项条目(数据元素词条)不可再分解的数据单位,包括: 名称 描述 数据类型 长度(精度) 取值范围及缺省值 计量单位 相关数据元素及数据结构
  • 67. 数据项条目说明举例数据项名:货物编号 别名:G-No,G-num 简述:本公司的所有货物的编号 类型:字符串 长度:10 取值范围及含义: 第1位:[J|G] (进口/国产) 第2∼4位:LB01.. LB29 (类别) 第5∼7位:“A00”..“A99” (规格) 第8∼10位:“001”..“999”(品名编号)
  • 68. (1)人工方法 (2)自动方法(利用字典管理程序) DD应具特点 (1)通过名字可方便查阅数据定义 (2)无冗余 (3)易更新修改数据字典实现方法
  • 69. 1. 确定系统边界, 画出系统环境图 2. 自顶向下,画出各层数据流图 3. 定义数据字典 结构化分析实施步骤
  • 70. 结构化分析方法的弊病基于功能分析和数据分析,将功能和数据分离,与人类现实世界环境不一样,和人的自然思维也就不一致了。 以功能为主,数据只是被动的信息载体。当系统行为发生变化时,系统维护非常困难。 DFD中不涉及系统的控制信息,因此,SA不适合于分析以控制信息为主的系统需求。
  • 71. 小结需求分析建模的过程 需求分析建模的方法 结构化分析 面向对象分析 Jackson分析 结构化分析 数据建模 功能建模和信息流 行为建模
  • 72. 第 6 讲 设计概念与原理
  • 73. 内容提要软件设计的重要性 设计过程 设计基本原则 设计概念 模块化设计 模块设计的启发规则
  • 74. 概述软件设计:应用各种技术和原理,对一个软件系统做出足够详细的决策,使之有可能在物理上得以实现的过程。软件是一个迭代的过程。 设计目标:将需求分析的结果(分析模型与需求分析规约)转化为实际软件系统的一个模型或软件表达式,即用于构造软件的“蓝图”。 最终产品:设计规约,包括描述体系结构、数据、过程和界面设计模型。 评审:清晰性、正确性、完整性。 软件设计与程序设计不同。
  • 75. 1. 软件设计的重要性软件需求分析和定义完成之后,进入软件设计阶段。 软件设计是构造和验证软件所需的技术(设计、编码、测试)之一。
  • 76. 开发阶段的信息流
  • 77. 翻译分析模型到软件设计THE ANALYSIS MODELproceduraldesigninterfacedesignarchitecturaldesigndatadesignTHE DESIGN MODELData object descriptionProcess specificationControl specificationE-RDFDSTDDDRepresentations of software that can be assessed for quality
  • 78. 翻译分析模型到软件设计数据设计将分析时创建的信息域模型变换为软件所需的数据结构,侧重于数据结构的定义。 体系结构设计定义软件系统各主要结构构件之间的关系。 过程设计则是把结构构件转换成软件的过程性描述。在编码步骤,根据这种过程性描述,生成源程序代码,然后通过测试最终得到完整有效的软件。 接口设计是建立软件内部的关系以及软件人-机之间的交互机制。 软件设计的重要性可以用“质量”表达。
  • 79. 软件设计的重要性软件设计是后续开发步骤及软件维护工作的基础。如果没有设计,只能建立一个不稳定的系统结构。
  • 80. 总体设计从回答“做什么”到回答“怎样做” 划分出组成系统的物理元素——程序、文件、数据库、过程和文档等等 每个元素还是黑盒子 ---“全局高度,抽象层次”
  • 81. 2. 设计过程从项目管理的角度来看,软件设计分两步完成。 概要设计,将软件需求转化为数据结构和软件体系结构。 详细设计,即过程设计。通过对体系结构表示进行细化,得到软件的详细的数据结构和算法。 P. 63 设计技术和管理方面之间的关系
  • 82. 设计和软件质量McGlaughlin提出的良好设计的演化的特征: 设计必须实现所有在分析模型中的显式需求,并且满足用户希望的隐式需求。 设计必须是可读的、可理解的指南,对于编码和测试人员。 设计应该提供软件的完整概貌。
  • 83. 设计和软件质量指导性原则 设计应该展示一种层次性结构。 设计应该模块化。 设计应该包括数据、体系结构、接口和模块(构件)的清楚的表示。 设计应有性质不同的可区分的数据结构和过程。 设计应该具有独立功能特征的模块。 设计应该降低模块和外部环境之间接口的复杂性。 设计应该利用需求分析中获得的信息和可重复的方法。
  • 84. 软件设计的演化模块化程序设计和自顶向下求精软件体系结构的方法。 结构化程序设计 面向数据流的程序设计 面向对象的设计方法 软件体系结构的设计 基于设计模式的软件设计
  • 85. 3. 设计基本原理软件设计概念提供了完善的设计方法,还可以帮助软件设计人员回答下列问题: 能使用什么标准将软件化分为单个构件? 如何将功能或数据结构的细节与软件的概念表达分离? 是否存在定义软件设计的技术质量的统一标准?
  • 86. 设计基本原理1. 抽象 Abstraction: 抽出事物的本质特性而暂时不考虑无关的细节。 忽略细节,分层理解问题,自顶向下层层细化,包括对过程、数据和控制抽象。 过程抽象:一个命名的指令序列,具有特定和有限的功能。 数据抽象是命名的数据集合,描述一个数据对象。 控制抽象隐含了不必说明的内部细节的程序控制机制。 是实现模块化的手段之一。doorimplemented as a data structuremanufacturer model number type swing direction inserts lights type number weight opening mechanismopenimplemented with a "knowledge" of the object that is associated with enterdetails of enter algorithmwalk to door; reach for knob; switch the knob open door; walk through; close door.
  • 87. 过程抽象例:开发一个CAD软件,实现一个二维绘图系统的全部功能,供低级计算机辅助设计使用。 抽象层次I:用问题所处环境的术语来描述这个软件。 该软件包括一个计算机绘图界面,向绘图员显示图形,以及一个数字化仪界面,用以代替绘图板和丁字尺。所有直线、折线、矩形、圆及曲线的描画、所有的几何计算、所有的剖面图和辅助视图都可以用这个CAD软件实现……。
  • 88. 过程抽象抽象层次II:任务需求的描述。列出“What”而不是“How”。 CAD SOFTWARE TASKS: user interaction task; 2-D drawing creation task; graphics display task; drawing file management task; END
  • 89. 过程抽象 抽象层次III:程序过程表示。以2-D绘图生成任务为例: PROCEDURE 2-D drawing creation REPEAT UNTILE (drawing creation task terminates) DO WHILE (digitizer interaction occurs) Digitizer interface task; DETERMINE drawing request CASE Line: line drawing task; Rectangle: rectangle drawing task; Circle: circle drawing task; …… END; DO WHILE (keyboard interaction occurs) keyboard interaction task; PROCESS analysis/computation CASE View: auxiliary view task; Section: cross sectioning task; …… END; …… END REPETITION; END PROCEDURE.
  • 90. 过程抽象在这个抽象层次上,给出了初步的过程表示,所用的术语都已面向软件,而且模块化的工作已经开始显露。 逐步细化和模块化的概念与抽象紧密相连。
  • 91. 数据抽象定义“绘图 drawing”数据对象作为一种抽象数据类型。 TYPE drawing IS STRUCTURE DEFINED number IS STRING LENGTH (12) geometry DEFINED … notes IS STRING LENGTH (256) … ENF drawing TYPE; Blueprint IS INSTANCE OF drawing; Schematic IS INSTANCE OF drawing;
  • 92. 设计基本原理2. 细化 Refinement: 自顶向下的设计策略。doorimplemented as a data structuremanufacturer model number type swing direction inserts lights type number weight opening mechanismopenimplemented with a "knowledge" of the object that is associated with enterdetails of enter algorithmwalk to door; reach for knob; Switch the knob; open door; walk through; close door.repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat
  • 93. 细化设计的细化过程与需求分析的划分类似,只是考虑的细节层次不同,而不是方法。 细化实际是一个详细描述的过程。 抽象与细化是互补的概念。
  • 94. 设计基本原理模块化: Modularity 模块是数据说明、可执行语句等程序对象的集合,是单独命名的并且可以通过名字来访问,例如过程、函数、子程序、宏、modula等。 软件被划分成独立命名和可独立访问的被称作模块的构件,每个模块完成一个子功能,它们集成到一起满足问题需求。 easier to build, easier to change, easier to fix ...
  • 95. 模块化模块化论据: 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) 不要过度模块化!每个模块的简单性将被集成的复杂性所掩盖。
  • 96. 模块化模块化和软件成本 如何确定地预测最小成本区?成本成本 / 模块最小成本区接口成本软件总成本模块数目
  • 97. 模块化如何确定模块的大小: 模块可分解性 模块可组装性 模块可理解性 模块连续性 模块保护
  • 98. 设计基本原理4. 软件体系结构 Architecture 是过程构件(模块)的层次结构、模块间交互的方式以及其使用的数据结构。 软件结构的演变从确定问题开始,当该问题的每个部分用一个或多个软件加以解决以后,整个问题的解也就有了。
  • 99. 软件体系结构结构的演化P3P1P2P4P5S1S2S3S4S5
  • 100. 体系结构
  • 101. 设计基本原理5. 控制层次 Control Hierarchy 也称为程序结构 深度:表示控制的层数。 宽度:表示控制(同一层次)总跨度。 扇出数:指由一模块直接控制的其他模块的数目。 扇入数:指有多少个模块直接控制一个给定的模块。 上级模块 从属模块
  • 102. 控制层次McbalkedmfgihjnopqrWidth DepthFan-outFan-in
  • 103. 控制层次控制层次代表了两种不同的体系结构特征:可见性 visibility 和连接性 connectivity 。 可见性:构件集合可以直接或间接引用一个给定构件作为数据。 连接性:构件集合直接引用一个给定构件作为数据。
  • 104. 设计基本原理Mcbalkedmfgh6. 结构划分 如体系结构是层次式的,则程序结构可以被水平划分和垂直划分。n
  • 105. 设计基本原理Mcbalkedmfgh6. 垂直划分 n
  • 106. 设计基本原理7. 数据结构 数据结构是数据元素之间逻辑关系的表示。 数据结构决定了信息的组织、访问方法、关联程度、可替换的处理方法。 典型的数据结构: 标量项、顺序向量、数组、链表、树、堆等。
  • 107. 设计基本原理8. 软件过程 software procedure 体系结构定义了控制层次,而软件过程着重于每个单独模块的处理细节。 过程必须提供精确定义,包括事件顺序、准确的抉择点、重复的操作,以及数据组织和结构。 体系结构与软件过程是相互关联的。
  • 108. 设计基本原理9. 信息隐藏 information hiding 信息隐蔽:应该这样设计和确定模块,使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说,是不可访问的。是实现模块化的手段之一。 The clients of a module know about its services only through its interface; the implementation is hidden from them (hence may change without affecting the clients). 隐藏就是有效的模块化可以通过定义一组独立模块来实现。
  • 109. 信息隐藏modulecontrolled interface"secret"• algorithm • data structure • details of external interface • resource allocation policyclientsa specific design decision
  • 110. 信息隐藏“信息隐藏”,更准确地描述应是“细节隐藏”,因为隐藏的不是信息,而是实现的细节。
  • 111. 4. 模块化设计实现模块化的手段:抽象和信息隐蔽。 在软件体系结构中,从绑定时间、激活机制和控制模式来划分模块类型。 在程序结构中,分为顺序、增量和并行模块。
  • 112. 模块化设计模块独立性 通过开发具有单一功能和反对同其它模块的过多交互的模块而实现的。 好设计的关键:每个模块完成一个相对独立的子功能,并且与其它模块间的接口简单。 好处:更有利于开发、设计/编码修改的副作用减小、模块的复用可能。 功能独立性是良好设计的关键,设计又是软件质量的关键。 度量标准:内聚 cohesion 和耦合 coupling 。 内聚是一个模块内部的交互程度;耦合是模块之间交互的程度。
  • 113. 内聚内聚:The elements of a module are directed to perform the same task. Goal: as cohesive as possible. 内聚级别: 偶然内聚 逻辑内聚 时间内聚 过程内聚 通信内聚 顺序内聚 功能内聚最差最好
  • 114. 内聚低内聚 偶然内聚(Coincidental cohesion): Unrelated functions, processes, or data are found in the same module (for convenience). 例:read disk file; calculate current values; produce user output; … 严重的缺点:产品的可维护性退化;模块是不可复用的,增加软件成本。 解决途径:将模块分成更小的模块,每个小模块执行一个操作。
  • 115. 内聚低内聚 逻辑内聚(Logical cohesion):Logically related functions or data are placed in the same module. 问题:接口难于理解;完成多个操作的代码互相纠缠在一起,导致严重的维护问题。 A: Read inputsfrom diskfrom tapefrom keyboard
  • 116. 内聚低内聚 时间内聚(Temporal cohesion): The functions are related only by the timing involved. 例如:系统的初始化 open old master file; new master file, transaction file and print file; initialize sales region table; read first transaction record and first old master file record; 问题:不同的功能混在一个模块中,有时共用部分编码,使局部功能的修改牵动全局。
  • 117. 内聚中内聚 过程内聚 (Procedural cohesion): Functions are grouped together in a module to ensure a certain order of performance. 例子: Read part number from database and update repair record on maintenance file.enter datacheck datamanipulate data
  • 118. 内聚中内聚 通信内聚(Communicational cohesion):All the functions in a module operate on or produce the same data set. 例如:从同一磁带上读取不相干的数据 —— 可能破坏独立性。
  • 119. 内聚高内聚 顺序内聚 (Sequential cohesion):The output from one part of a module is the input to the next part. 功能内聚 (Functional cohesion):Every processing element is essential to the performance of a single function. 原则:在实际工作中,确定内聚的精确级别是不必要的,重要的是力争高内聚和识别低内聚,可以使得设计的软件具有较高的功能独立性。
  • 120. 内聚示例计算多个地点的每日平均温度功能聚合初始化“求和” 并打开文件偶然聚合关闭文件并打印平均温度偶然聚合创建新的 温度记录功能聚合存储温度记录功能聚合读取地点、时间和温度功能聚合编辑地点、时间和温度字段逻辑聚合存储特定地点的温度功能聚合??
  • 121. 耦合耦合是度量系统中模块之间的交互程度。 Goal: as loose as possible = as independent as possible 耦合从低到高依次为:非直接耦合(最好),数据耦合,标记耦合,控制耦合,外部耦合,公共耦合和内容耦合(最差)。 Great deal of dependenceIndependent Highly coupledLoosely coupledUncoupled 
  • 122. 耦合内容耦合 content coupling 如果两个模块中的一个直接引用了另一个模块的内容,则它们之间是内容耦合。 One module modifies another. ……ABCDA: ………… ………… goto C1 ………… …………C: ………… ………… C1: …… ……例1:A访问C的内 部数据或不通过正常入口而转入C的内部。
  • 123. 例2:部分代码重叠(常出现在汇编程序中)B A例3:一个模块有多个入口(功能)A: ……………… ……………… entry 1: ……………… ……………… entry 2: ……………… ……………… The least desirable must be avoided耦合
  • 124. 耦合公共耦合 common coupling 如果两个模块都可以存取相同的全局数据,则它们之间是公共耦合。 Data are accessible from a common data store. Global : V1 V2A: ………… ………… A1=V1+V2 ………… …………B: ………… ………… V1=B1 ………… …………Global : V1 V2A: ………… ………… V1++ ………… …………B: ………… ………… V2=B1+V1 ………… …………
  • 125. 耦合公共耦合存在的问题: 公共部分的改动将影响所有调用它的模块; 公共部分的数据存取无法控制; 复杂程度随耦合模块的个数增加而增加。 解决方法: 通过使用信息隐藏来避免公共耦合。
  • 126. 耦合外部耦合 external coupling 当模块与软件的外部环境联结在一起,并受到约束时就出现较高程度的耦合,则它们之间为外部耦合。 ANMLFEDCBOPE和L为外部模块;C、F和N为公共模块;B和D为内容模块
  • 127. 耦合控制耦合 control coupling 如果两个模块中的一个模块给另一个模块传递控制信息,则它们具有控制耦合。 One module passes parameters to control the activity of another module.ABFlagF2F1Fn…………Flag特点:接口单一,但仍然影响被控模块的内部逻辑。
  • 128. 耦合标记耦合 stamp coupling 如果两个模块都要使用同一数据结构的一部分,不是采用全局公共数据区共享,而是通过模块结构传递数据结构的一部分,则它们之间为标记耦合。 数据耦合 data coupling 被调用模块的输入与输出是简单的参数或者是数据结构(该数据结构中的所有元素为被调用的模块使用),则它们之间为数据耦合。 非直接耦合 no direct coupling 两个模块之间没有联系,则它们之间为非直接耦合。 The most desirable.
  • 129. 耦合实现低耦合,采取下列措施: 耦合方式 采用非直接耦合,不采用融合耦合。 传递信息类型 尽量使用数据耦合,少采用控制耦合,外部耦合和公共耦合限制使用。 耦合数量 模块间相互调用时,传递参数最好只有一个。 原则:尽量使用数据耦合,少用控制耦合,限制公共耦合的范围,完全不用内容耦合。
  • 130. 2. 模块规模适中:过大分解不充分不易理解;太小则开销过大、接口复杂。注意分解后不应降低模块的独立性。 3. 适当控制 —— 深度 = 分层的层数。过大表示分工过细。 宽度 = 同一层上模块数的最大值。过大表示系统复杂度大。1. 争取低耦合、高内聚(增加内聚 > 减少耦合)启发性规则
  • 131. 启发性规则系统结构
  • 132.  扇出 = 一个模块直接调用\控制的模块数。 3  fan-out  9AA的扇出AA的扇入 扇入 = 直接调用该模块的模块数 在不破坏独立性的前提下,fan-in 大的比较好。启发性规则
  • 133. 启发性规则尽可能减少高扇出结构,随着深度增大扇入。 如果一个模块的扇出数过大,就意味着该模块过分复杂,需要协调和控制过多的下属模块。应当适当增加中间层次的控制模块。 一般来说,顶层扇出高,中间扇出少,低层高扇入。
  • 134.  控制域MACBM的控制域为 {M,A,B,C} 作用域:M中的一个判定所影响的模块。 启发性规则 作用域是指该模块中一个判断所影响的所有其它模块; 控制域指该模块本身以及所有直接或间接从属于它的模块。 4. 模块的作用范围保持在该模块的控制范围内
  • 135. 例:A: ………… if …… then goto B1 ………… …………B: ………… ………… B1: ………… …………作用域在控制域内A: ………… if …… then goto M1 ………… …………M: ………… ………… M1: goto C1 ………… …………作用域超出了控制域 上例中A的作用超出了控制域。 改进方法之一,可以把A中的 if 移到M中; 改进方法之二,可以把C移到A下面。MACB
  • 136. 5、降低接口的复杂程度:模块接口的复杂性是引起软件错误的一个主要原因。接口设计应该使得信息传递简单并且与模块的功能一致。 6、单出单入,避免内容耦合,易于理解和维护。 7、模块功能可预测 —— 相同输入必产生相同输出。反例:模块中使用全局变量或静态变量,则可能导致不可预测。 启发性规则
  • 137. 小结软件设计的重要性 设计过程 设计的基本原理 抽象、细化、模块化、体系结构、控制层次、数据结构、软件过程、信息隐藏。 模块化设计 内聚、耦合,启发规则。