软件工程-第3章软件需要分析

LOGO 第 5章 软件需求分析 为什么要进行需求分析？ 目的：对开发者进行指导 开发人员对用户的要求理解 用户理解开发人员 测试部门有理可依 原因：信息收集不全 功能不明确 需求文档不完善 开发者急于求成 教学内容 3.1 需求分析的任务和步骤 3.2 需求获取的常用方法 3.3 分析建模 3.4 软件需求说明 3.5 结构化分析方法 3.6 面向对象分析方法 教学目的及要求 深刻理解需求分析阶段的概念和任务； 熟练掌握数据流图； 了解面向过程分析方法和面向对象的分析方法。 1.需求分析的任务： 准确地定义未来系统的目标，确定为了满足用户的需求系统必须做 什么。用 规范的形式准确地表达用户的需求。 让用户和开发者共同明确将要开发的是一个什么样的系统（做什么 ： What）。具体而言 ,两个任务： 建立分析模型 编写需求说明（ P30-P31） 3.1 需求分析的任务和步骤 需求分析的任务 就是借助于当前系统的逻辑模型导出目标系 统的逻辑模型，解决目标系统的 “做什么” 的问题。 需求分析的任务 对象 系统 模型 系统 抽象（映射） 模型应用 模型构造的过程 逻辑模型和物理模型 模型是对对象系统的形式化的特征抽象，概括性或近似地表示； 形式 化语言、数学语言、图形等构造模型的过程是一个抽象、分析的过程。 逻辑模型和物理模型 逻辑模型 (本质模型、概念模型 ) 物理模型 (实施模型、技术模型 ) 现行系统 描述重要的业务功能，无论系统是 如何实施的 描述现实系统是如何在 物理上实现的。 目标系统 描述新系统的主要业务功能和用户 新的需求，无论系统应如何实施。 描述新系统是如何实施 的（包括技术）。 2.需求分析的步骤 需求获取 需求提炼：分析建模 需求描述：编写 需求验证 3.1 需求分析的任务和步骤 需求分析过程示意 学 生 购 书 申 请 购 书 单 发 票 领 书 单 书 107 刘 教务科 206 王 会计室 206 李 出纳员 303 赵 教材 学生购买教材的具体模型 (1) 通过对现实环境的调查，获当前系统的具体模型 (物理模型 ) 学 生 需求分析过程示意 (2) 去掉具体模型中的非本质因素， 抽象 出当前系统的逻辑 模型 学生购买教材的逻辑模型 学 生 学 生 购 书 申 请 购 书 单 发 票 领 书 单 书 审查 有效性 开发票 开领 书单 发书 需求分析过程示意 (3) 分析当前系统与目标系统的差别，建立目标系统的逻辑 模型。 计算机售书系统的逻辑模型 学 生 学 生 购书单 发票 领书单 审查并 开发票 开领 书单 需求分析过程示意 (4) 对目标系统进行完善和补充，并写出完整的需求说明； (5) 对需求说明进行复审，直到确认文档齐全，并且符合用 户的全部需求为止。 3.2 需求获取的常用方法 1.需求获取的目的 清楚地理解所要解决的问题 完整地获取用户需求 2.需求获取面临的挑战 问题的复杂性和对问题空间理解的不完 备性与不一致性 交流障碍 需求易变性 3.2 需求获取的常用方法 3.需求获取的常用方法（ P34-P35） 建立联合分析小组 客户访谈 问题分析与确认 3.2 需求获取的常用方法 建立联合分析小组 1）联合分析小组的人员主要包括：用户、领域专家、 系 统分析员 2）通过联合分析小组的工作，可以极大地方便系统开发 人员和用户之间的沟通。 3.需求获取的常用方法 客户访谈 在与用户接触之前，先要进行充分的准备 ： 注意：在与用户交流时，应遵循循序渐进、逐步逼近的原则， 切不可急于求成否则欲速则不达。 3.需求获取的常用方法 首先，必须对问题的背景和问题所在系统的环境有全面的了解； 其次，尽可能了解将要会谈用户的个性特点及任务状况； 第三，事先准备一些问题。 问题分析与确认 不能期望用户在一两次交谈中，就会对目标软件的 要求阐述清楚，也不能限制用户在回答问题过程中的自 由发挥。 在每次访谈之后，要及时进行整理，分析用户提供 的信息，去掉错误的、无关的部分，整理有用的内容， 以便在下一次与用户见面时由用户确认；同时，准备下 一次访谈时的进一步更细节的问题。如此循环，一般需 要 2-5个来回。 3.需求获取的常用方法 举例：某出版社系统调查表 编号 提出问题 1 您在哪个部门工作？ 2 出版业务流程是什么？ 3 您每日都处理那些文件、数据、报表？ 4 工作中手工处理特别麻烦的事情是什么？ 5 工作中手工处理什么问题解决不了？影响效率的问题有哪些？ 6 您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些 办法？ 举例：某出版社系统调查表 编号 提出问题 7 您的部门需要成本核算和统计的内容有哪些？ 8 您的部门采用计算机管理工作情况如何？ 9 如何改进业务流程使之更合理？ 10 哪些问题是目前传统手工方法根本无法解决的？ 11 出版社计算机管理信息系统需要解决什么问题？ 软件需求分析的通信途径 需求分析流程 4. 需求获取的内容 (1)功能性需求 : 定义了系统做什么（描述系统必须支持的功能和过程） (2)非功能性需求（技术需求） : 定义了系统工作时的特性（描述操作环境和性能目标） 用户需求分类 两类需求包括的内容 (1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档 (7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (11)质量保证 4. 需求获取的内容 (1) 功能需求 系统做什么？ 系统何时做什么？ 系统何时及如何修改或升级？ (2) 性能需求 软件开发的技术性指标 例如： 存储容量限制 执行速度、相应时间 吞吐量 (3) 环境需求 硬件设备：机型、外设、接口、地 点、分布、温度、湿度、磁场干扰等 软件： 操作系统 网络 数据库 (4) 界面需求 有来自其它系统的输入吗？ 到自其它系统的输出吗？ 对数据格式有规定吗？ 对数据存储介质有规定吗？ 需求包括的内容 (5) 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？ (6) 文档需求 需哪些文档？ 文档针对哪些读者？ (7) 数据需求 输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？ (8) 资源需求 软件运行时所需的数据、软件、 内存空间等资源。 软件开发、维护所需的人力、支 撑软件、开发设备等。 需求包括的内容 (9) 安全保密要求 需对访问系统或系统信息加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序和操作系统隔离？ 系统备份要求？ (10) 软件成本消耗与 开发进度需求 开发有规定的时间表吗？ 软硬件投资有无限制？ (11) 质量保证 系统的可靠性要求？ 系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后，重启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？ 需求包括的内容 原型 (原型指 “ 快速软件原型 ” )是一个可实地 运行 的 模型 ,有正式产品的主要特征，但不是全部特征。 软件原型是软件系统的最初版本，以最少的费用，最 短的时间开发出的、以反映最后软件的主要特征的系统。 5. 快速原型法在需求分析中的应用 原型开发指的是建立一个系统的早期版本的演习 (practice)，它不必反映最终产品的所有性能，而只要反映感 兴趣的一些方面。 原型的定义 原型的作用 问题：开发初期很难确定用户需求规格解决：用户与开发 者之间的鸿沟以原型 (软件产品的样品 )为共同语言，实现用户 与开发者双向沟通。 原型的特性 是一个可实际工作的系统； 没有固定的生存期 ,结局可能是用后立即被抛弃 ,或可能成为 最终系统 ; 可服务于不同的目的 , 从需求分析到最终产品都可做原型 ; 建立必须快 ,便宜 ; 是包含修改 、 评价在内的完整重复过程 需求分析和定义规格说明 作为软件设计的一种工具 作为一种解决不确定性的工具 作为一种实验工具 系统开发同时 ,作为同步培训工具 作为开发方法，利用原型演化为最终系统 作为软件维护的辅助工具 原型化开发的应用领域 原型开发的步骤 (1) 利用各种分析技术和方法，生成一个建华的需求规格说明。 (2) 对需求规格说明进行必要的检查和修改后，确定原型的软件结构、 用户界面和数据结构等。 (3) 在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测 试、改进； (4)将原型提交给用户评估并征求用户的修改意见； (5)重复上述过程，直到原型得到用户的认可。 原型化的开发环境 (1)试验性原型 原型用来确认对需求的理解是否正确，应在与实际产品环 境相近的环境上开发原型。 (2) 试用性原型 原型用来帮助用户在试用中使自己的模糊的需求明确起来 确，可在与实际产品环境完全 无关的环境上开发运行。 仅对屏幕的原型化 使用购买的软件系统作为 初始模型 可行性分析中的原型 子系统原型化 原型化策略 功能原型开发 用户界面原型开发 原型开发技术 原型化工具 面向应用的第四代语言 (4GL) Delphi VB PowerBuilder Visual C+ 等 原型法效果 保证产品有较好的可维护性 改善用户与开发人员的信息交流和思想沟通，给用户修改的机会 减少或消灭下游返工的可能，改进了瀑布模型的弊病 原型系统可作为培训环境 ,有利于用户培训和开发同步。 开发成本降低，周期缩短。 原型法局限性 需工具支持 ， 否则开发工作量大； 只能缩短用户与软件需求定义间的距离 ， 并不能消灭这个距离； 考虑你的项目是否适合用原型法来开发时 ， 有几个因素是要权衡的 。 Boehm,Gray,和 Seewaldt(1984) 研究了项目是否适合用原型来开发的 问题 。 他们发现用原型法开发项目 ， 可以少花费 45%的努力 ， 还可以 减少 40%的代码 。 而且 ， 开发出的产品的速度和效率与用传统方法开 发出的差不多 。 是否要选择原型法？ 由于开发一个原型需要花费一定的人力、物力、财力和时间， 而且用于确定需求的原型在完成使命后一般就被丢弃。因此，是 否使用快速原型法必须考虑软件系统的特点、可用的开发技术和 工具等方面。 Andriole提出的一下 6个问题，可用来帮助判断是 否要选择原型法。 需求已经建立，并且可以预见是相当稳定吗？（肯定回答，不 采用原型法） 软件开发人员和用户已经理解了目标软件的应用领域吗？ 问题是否可被模型化？ 用户能否清楚地确定基本的系统需求？ 有任何需求是含糊的吗？ 已知的需求中存在矛盾吗？ （以上 5个问题肯定回答，用原型法） 3.3 分析建模 两种分析模型 结构化分析模型 面向对象分析模型 计算机世界 现实世界 结 构 化 开 发 方 法 结构化 分析 结构化 设计 结构化 编程 OOA OOD OOP 面 向 对 象 开 发 方 法 结构化分析模型的组成结构 数据流图 (DFD) E-R图 状态变迁图 (STD图 ) 加 工 说 明 控制说明 数 据 对 象 说 明 数据字典 （ DD） 结构化分析模型的组成结构 模型的核心是 DD（ Data Dictionary,数据字典），它是系统所涉及的 各种数据对象的总和。 从 DD出发可构建 3种图： E-R图 （ Entity-Relation Diagram，实体 -关系图）用于描述数据对 象间的关系，他代表软件的数据模型，在实体 -关系图中出现的每个 数据对象的属性均可用数据对象说明来描述； DFD图 （ Data Flow Diagram，数据流图），其主要作用是指明系统中 数据是如何流动和变换的，以及描述是数据流进行变换的功能，在 DFD图中出现的每个功能的描述则写在（ PSPEC）中，它们一起构成功 能模型； STD（ Status Transfer Diaram，状态 -变迁图），用于指明系统在外 部时间的作用下将会如何动作，表明了系统的各种状态以及各种状态 间的变迁，从而构成为行为模型的基础，关于软件控制方面的附加信 息则包含在控制说明（ CSPEC）。 面向对象分析模型的组成结构 对象 -关 系模型 类 /对象 模型 对象 -行为模型 使用实例 (Use Case) 操作、 面向对象分析模型的组成结构 使用实例， 处于 OOA模型核心的是“使用实例”（ Use Case ），简称 “用例”。获得软件的需求后，软件分析员既可据此创建一组“场景” （ Scenario），每个场景包含一个使用实例。从这些用例出发，进一 步抽取和定义 OOA模型的 3种模型，即 类 -对象模型 ， 描述系统所涉及的全部类 -对象，每个类 -对象都通过 属性、操作和写作者来进行进一步描述； 对象 -关系模型 ， 描述对象之间的静态关系，同时定义了系统中所有 重要的消息路径，它也可以具体化到对象的属性、操作和协作者； 对象 -行为模型 ， 描述了系统的动态行为，即对湘杂特定的状态下如 何反映外界的事件。 数据流图 (DFD) 数据字典 (DD) 加工说明 控制流图（ CFD）与控制说明（ CSPEC ） 状态转换图 (STD) E-R图 用例图 对象关系图（ Object-Relationship,O-R） 对象行为图 2.分析模型的组成与描述工具 分析模型的组成与描述工具 DFD、 DD和 PSPEC：是早期结构化分析模型 的基本组成部分； CFD、 CSPEC和 STD是扩展成分用以适应实时的 建模需要； E-R图：适用于描述具有复杂数据结构的软件数据 模型； 用例图、对象关系图和对象行为图适用于 OOA的分 析模型。 数据流图 (DFD) 任何软件系统（或计算机系统）从根本上说，都是对数据 进行加工或变换的工具 指明数据在系统中移动时如何被变换； 描述对数据流进行变换的功能； DFD中每个功能的描述包含在加工规约小说明 )中。 数据存储 (文件或数据库） 数据流图的四个基本成分 数据流（数据对象） 位于被建模系统之外的信息生产者或消费者 , 称为外部项。 说明数据输入的源点 (数据源 )或数据输出的 汇点 (数据池 ) 或 2 或 2 或 II 数据处理 (加工 ) 数据流 表示数据和数据流向， 三个重要属性 : 流向 (从加工出发或流向加工 ) 数据组成 数据流名字 数 据流命名方法和注意事项 用名词或名词词组，不要使用意义空洞的名词； 尽量使用现实系统已有名字 ,当命名出现困难，考虑是否数据流划 分不恰当； 不要把控制流作为数据流指明作为外部事件的结果 ,系统将如何动 作。 举例 ： 购 书 单 发票 领书单 审查并 开发票 开领 书单 无效书单 学生 1 2 各班学生 用 书 表 学生 教材存量表 数据字典 (DD， Data Dictionary) 模型核心 (中心库 ) 一个软件系统含有许多数据。数据字典的作用，就是对软件中 的每个数据规定一个定义条目，以保持数据在系统中的一致性。 由字典统一给出的所有数据的定义与属性，已成为结构化分析 中分析建模的基础。 数据词典与数据流图配合，能清楚地表达数据处理的要求 词条描述 对于在数据流图中每一个被命名的图形元素， 均加以定义，其内容有 : 名字 ， 别名或编号 ， 分类 ， 描述 ， 定 义 ， 位置 ， 其它 ， 等 数据字典 DD是对所有与系统相关的数据元素的一个有组织的列表 ,以及 精确的、严格的定义 ，使得用户和系统分析员对于输入、输出、 存储成分和中间计算有共同的理解 DFD中的数据流、数据存储表示某个有组织的数据集合，它 们要由 SA的其他描述工具 -需求字典 (数据字典 )来描述，包括： 词条描述、 数据结构描述、 加工逻辑说明 作用 : 数据字典 数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定 义的集合 数据字典的内容 数据流 数据流分量 数据存储 处理 数据处理：用 IPO图或 PDL描述比较方便直观。 数据元素的别名： 定义数据的方法 由数据元素组成数据的方式的三种基本类型 顺序 +： 以确定次序连接两个或多个分量 a+b+c 选择 |， ： 从两个或多个可能的元素中选取一个 a | b | c 重复 ： 把指定的分量重复零次或多次 a 可选：一个分量是可有可无的（重复零次或一次） , （ a） 例子 定货报表 =零件编号 +零件名称 +定货数量 +目前价格 +主要供应者 +次要供应者 零件编号 =8字符 8 定货数量 =1数字 5 数据流词条描述 数据流名： 说明：简要介绍作用即它产生的原因和结果 数据流来源：来自何方 数据流去向：去向何处 数据流组成：数据结构 数据量流通量：数据量，流通量 数据元素词条描述 数据元素名： 类型：数字（离散值，连续值），文字（编码类型） 长度： 取值范围： 相关的数据元素及数据结构： 数据文件词条描述 数据文件名： 简述：存放的是什么数据 输入数据： 输出数据： 数据文件组成：数据结构 存储方式：顺序，直接，关键码 存取频率： 加工逻辑词条描述 加工名： 加工编号：反映该加工的层次 简要描述：加工逻辑及功能简述 输入数据流： 输出数据流： 加工逻辑：简述加工程序，加工顺序 F1:航班信息文件 航空公司名称航班号 起点终点日期 起飞时间降落时间 航空公司名称 2字母 4 航班号 3十进制数字 3 字母“ A”“Z” 十进制数字“ 0”“9” 起点终点 1汉字 10 起飞时间降落时间时分 时“ 00”“23” 分“ 00”“59” 日期年月日 年 2000 2001 2002 2004 月“ 01”“12” 日“ 01”“31” 重复项： 起点终点 1汉字 10 航空公司名称 2字母 4 航班号 3十进制数字 3 组合项： 日期年月日 起飞时间降落时间时分 选择项： 年 2000 2001 2002 2004 原数据项： 字母“ A”“Z” 十进制数字“ 0”“9” 时“ 00”“23” 分“ 00”“59” 月“ 01”“12” 日“ 01”“31” 定义式中使用的符号 操作符 含义描述 定义为 与 (顺序结构 ) . 重复 (循环结构 ) . . 或 (选择结构 ) . , . ( . ) 任选 m.n 界域 ., 注释符 限制重复次数举例 : 3 5 或 5 3 表示允许重复 3-5次 3 3 或 3 3 表示恰好重复 3 次 1 表示至少出现 1 次 表示允许重复 0至任意次 源点及汇 (终 )点词条描述 简名称：外部实体名 要描述：什么外部实体 有关数据流： 数目： 数据结构的描述 符 号 含 义 举 例 被定义为 与 x = a b .,. 或 .|. 或 x = a , b， x = a | b . 或 m.n 重复 x = a， x = 3a8 (.) 可选 x = (a) “.” 基本数据元素 x = “ a” . 连结符 x = 1.9 存折格式 存折户名所号帐号开户日性质 (印密 ) 1存取行 50 户名 2字母 24 所号“ 001”.“999” 帐号“ 00000001”.“99999999” 开户日年月日 性质“ 1”.“6” 注：“ 1” 表示普通户，“ 5” 表示工资户等 印密“ 0” 注：印密在存折上不显示 存取行日期（摘要）支出存入余额操作复核 出现在软件中的数据可分为 3种情况： 只含一个数据的数据项（或数据元素）； 由多个相关数据向组成的数据流； 数据文件或数据库。 举例说明怎样编写各类数据的字典条目： 数据流 数据文件 数据项 数据流条目说明举例 数据流名 :发票 别名 : 购书发票 组成 :(学号 )姓名书号单价数量总价 书费合计 数据量 :100次 /天 高峰值：开学期间 400次 /天 数据存储条目说明举例 文件名 :各班学生用书表 别名 : 组成 ： 系编号专业和班编号 年级 书号 组织 ：按系、专业和班编号从小到大 排列 存取要求 :关键字是专业和班编号 数据项条目说明举例 数据项名 :系编号 别名 : 取值： 2数字 2 注释 : * 例如 : 01,12 * 数据项条目说明举例 数据项名 :专业和班编号 别名 : 取值： 3数字 3 注释 : * 例如 : 305 * 数据项条目说明举例 数据项名 :年级 别名 : 取值及含义 : freshmen, 一年级 sophomore,二年级 junjor, 三年级 senior, 四年级 注释 :F,M,J,S可分别用 1,2,3,4代替 数据项条目说明举例 数据项名 :书号 别名 : 取值 : 字母 数字 注释 : * 例如 :， * 对数据流图的每一个基本加工，必须有一个基本加工逻辑说明 基本加工逻辑说明必须描述基本加工 如何把输入数据流变换为 输出数据流的加工规则 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节 加工逻辑说明中包含的信息应是充足的，完备的，有用的，无 冗余的 基本加工逻辑说明 用于写加工逻辑说明的工具 结构化英语 判定表 判定树 结构化英语 结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。 是一种介于自然语言和形式化语言之间的语言 语言的 正文用基本控制结构进行分割 ，加工中的 操 作用自然语言短语来表示 其基本控制结构有三种： 简单陈述句结构 ：避免复合语句； 重复结构 ： while_do 或 repeat_until 结构。 判定结构 ： if_then_else 或 case_of 结构； 商店业务处理系统中 “ 检查发货单 ” if 发货单金额超过 $500 then if 欠款超过了 60天 then 在偿还欠款前不予批准 else （欠款未超期） 发批准书，发货单 else （发货单金额未超过 $500） if 欠款超过 60天 then 发批准书，发货单及赊欠报告 else （欠款未超期） 发批准书，发货单 判定表 如果数据流图的加工需要依赖于 多个逻辑条件的取 值 ，使用判定表来描述比较合适 以 “ 检查发货单 ” 为例 判定树 判定树也是用来表达加工逻辑的一种工具。有时侯 它比判定表更直观。 检 查 发 货 单 金额 $500 金额 $500 欠款 60天 不发出批准书 欠款 60天 发货单 发出批准书、 欠款 60天 发出批准书、 发货单及赊欠报告 欠款 60天 发出批准书、 发货单 控制流图（ CFD）与控制说明（ CSPEC） CFD是为了适应实施系统地分析而提出的，通常与 DFD配合使用，目的使 CSPEC分析员在用 DFD和 PSPEC表 示数据流和加工的同时，也能够用 CFD和 CSPEC表示控 制流和控制加工。（ P45-P47） 数据流和控制流举例 动作 警告 监控固件和 操作接口 每个固件状态 机器人初 始化控制 操作命令 部件状态缓冲器 位置 命令 开始 /停止 处理 机器人命 令 机器人命令文件 操作 设置 处理活动 记录机器 人动作 位串 数据和控制模型的关系 DFD 加工规约 加工模型 DFD 控制规约 控制模型 数据输出 数据条件 数据输入 控制输入 控制输出 加工 激活者 SafeHome的控制面板 与用户 交互 SAFEHOME ARMED POWER 01 1 2 3 4 5 6 7 8 9 * 0 # OFF ARAY STAY MAX TEST BYPASS INSTANT CODE CHIME READY panic alarm check fire away stay instant bypass not ready SafeHome的第 0层 SafeHomede 软件系统 用户命令 和数据 显示信息 控制面板 传感器 状态 警告类型 电话号 码拨音 传感器 电话线 警铃 控制面板显示 SafeHome的第 1层 控制 面板 与用户 交互 控制 面 板 显 示 密码 电话号码拨音 传感器状态 显示 信息 配置请求 用户命令 和数据 配置 系统 警 铃 电 话 线 传感器 配置信息 显示信息 和状态 监控 传感器 激活不 激活系统 传感器信息 密码 处理 警告类型 检验 id信息 开始 停止 状态信息 监控传感器的第 2层 电话号码拨音 传感器状态 配置数据 显示格式 配置信息 产生警告 信息 拨号 评估设置 传感器信息 读传感器 警告类型 传感器 id类型 传感器 id 类型定位 SafeHome的第一层 控制面 板 与用户 交互 控制 面 板 显 示 显示活动状态（ 完成、在处理中 ） 配置 系统 警 铃 电 话 线 传感器 配置信息 显示信息 和状态 监控 传感器 激活不 激活系统 警告 信号 密码 处理 传感器 事件 警告 状态 超 时 闪烁标志 开关切换 状态转换图 (STD) 描述软件状态的变迁，它是在 CSPEC中常用的一种重要 描述工具。（ P48） 电梯 状态图举例 在一楼 上升 停滞 下降 回到一楼 回一楼 想要到 达楼层 想要到 达楼层 电梯行程 开始 向上 向上 向下 概念模型和规范化 用户的数据要求 -需要哪些数据，数据之间有哪些联系，数据本身有哪些性 质，数据的结构 等）。 用户的处理要求 -对数据进行哪些处理，每个处理的逻辑功能。 概念性模型（信息模型） -一种面向问题的数据模型，是按照用户的观点来 对数据和信息建模。表示概念性数据模型的最常用方法是 实体 -联系方法 ，采用用 ER图的方式，这种表示又称为 ER模型 。 ER模型 实体： 客观世界中存在的且可区分的事物。 联系： 客观事物之间的联系（三类 -1： 1， 1： N， M:N） 属性： 实体或联系所具有的性质。 教师 姓名 性别 职称 职务 教师号 教 1 课程 N 课程号 课名 学时 学分 学 M 学生 N 学号 姓名 性别 系 年级 成绩 范式 通常用范式定义消除数据的冗余度（略） E-R图 数据及数据库需求 在数据词典中，强调对数据存储结构的逻辑设计，并 用数据结构表达数据项之间的逻辑关系。 但任何一个软件系统都可能有成千上万个数据项，仅 仅描述这些数据项是不够的，更重要的是如何把它们 以最优的方式组织起来，以满足系统对数据的要求。 E-R方法 ( Entity-Relationship Approach) 和实体模型 在需求分析阶段进行数据库逻辑设计过程中， 使用 E- R图，可定义一 个实体模型 。 实体模型是现实世界的纯表示 ，它不涉及数据世界的 数据结构、存取路径、存取效率等问题。因此，它 可 以转换成数据库中的数据模型 。 E-R图中的基数表示： 在 E-R图中，每个 方框 表示 实体型 或 属性 ，方框之间 的 连线 表示 实体之间 ，或 实体与属性之间的联系 。出 现在连线上的短竖线可以看成是“ 1” ，而圆圈隐含 表示“ 0” 。 例如，在教学管理中，一个教师可以教授零门、一门 或多门课程，每位学生也需要学习几门课程。因此， 教学管理中涉及的对象（实体型）有 学生 、 教师 和 课 程 。 用 E-R图描述它们之间的联系，得下图。其中，学生 与课程是多对多的联系，而教师与课程的联系是零、 一对多。 进一步，要确定属性。例如， 学生具有 学号 、 姓名 、 性别 、 年龄 、 专业 （其它略） 等属性； 课程具有 课程号 、 课程名 、 学分 、 学时数 等属性； 教师具有 职工号 、 姓名 、 年龄 、 职称 等属性。 此外，学生通过学号、分数与课程发生联系。如此可 得教学实体模型。 教学实体模型 数据库分析的过程 在需求分析阶段进行数据库分析的流程 为开发一个系统所使用的数据库，在开始分析数据库 的需求前，分析员必须 了解该系统的总目标和范围 。 然后 建立一个完整并高度细化的信息模型 。 此信息模型应包括一个 综合的数据词典 ，定义所有在 开发数据库时用到的数据项。 接着数据库分析定义数据库的 逻辑特性 和 物理特性 。 用例是帮助分析员和用户确定系统使用情况的 UML组件； 一组用例就是从用户的角度出发如何使用系统的描述； 可认为用例是系统的一组使用场景； 每个场景描述了一个事件的序列； 每个序列是由一个人、另一个系统、一个硬件设备或某段时间 的流逝所发起； 每个发起事件序列的实体叫做 参与者（ actor） 或 行动者 什么是用例（ use case）？ 用例图 用例建模 用例建模是用于描述一个系统应该做什么的建模技术 用例建模可用于新系统的需求获取，也可用于已有系 统的升级 用例模型（ use case model） 一个用例模型可由若干幅用例图组成 用例描述了用户和系统之间的交互，其重点是 系统为 用户做什么 用例模型描述全部的 系统功能行为 一幅用例图包含的模型元素有： 用例 参与者（行为者、执行者） 系统 用例 参与者 系统 参与者 通信 关系 用例模型表示法 销售系统用例图 购买商品 登录 退货 收款 员 POS 顾客 购买商品 退货 商店 顾客 以商店作为系统边界 以 POS作为系统边界 POS系统用例图 购买商品 登录 退货 收款 员 POS 顾客 启动 /关闭 管理用户 其他 管理员 系统管理员 参与者与它们所发起执行的过程（简要描述） 现金结算 登录 收款员 退货 购买商品 顾客 关闭系统 启动系统 管理员 增加新用户 系统管理员 用例描述实例 用例： 购买商品 参与者：顾客（发起者）、收款员 类型： 主要的 描述： 顾客带着所要购买商品到付款处，收款员 记录商品信息并收款。 用例： 启动 /关闭系统 参与者：管理员 类型： 主要的 描述： 管理员接通一台 POS机电源，检查时间、 日期正确性，检查完成后，系统处于就绪 状态，以备收款员使用。 对象关系图（ Object-Relationship,O-R） 对象关系图是由 E-R图演变而来的。对象通过制定的关系 和其他对象连接，规定连接的基数并建立整体的对象 -关 系网络。 金融机构类图举例 ： 所有人 财产 人员 金融机构 信贷银行 银行 抵押 本金 利率 到期 * * 有次序的 * * * 借方 债权人 房 屋 保险机构类图举例 ： 销售代表 0 . 1 定货 name address 顾客 creditRating( ):String 产品 雇员 1 dataReceived isPrepaid number:String price:Money 协作顾客 contactName creditRating creditLimit creditCard# 个人顾客 creditRating( ) =“poor” 定货作业线 dispatch( ) close( ) remind( ) billForMonth( ) Quantity:Integer price:Money isSatisfied:Boolean 1 * * * * 1 物品 网上商店对象模型 (部分 )示例 (UML) 对象行为图 对象行为模型用于描述对象动态行为，通常由对象状 态转换图、事件轨迹图和事件流图等来描述。（ P52-P53） 电梯 状态转换图 在一楼 上升 停滞 下降 回到一楼 回一楼 想要到 达楼层 想要到 达楼层 电梯行程 开始 向上 向上 向下 接电话的的部分事件轨迹图 ： 受话者 交换机 远程交换机 受话者 拿起话筒 听通话声 拨号码 . 铃响信号 铃响 铃响停止信号 拿起话筒 铃响停止 10 d e a b c b-a1 e-d5 c-b10 路径 文档打印系统的部分事件流图 打印机忙 保存打印文件 队列 计算机 打印机空闲 打印文件 打印机 打印服务器 打印文件 4、软件需求说明书 (SRS) (Software Requirement Specification) SRS的作用： 开发者与用户间事实上的技术合同书 开发者下一步设计和编码的基础 测试验收目标系统的依据 软件需求说明（ SRS） 引言 信息描述 功能描述 行为描述 质量保证 接口描述 其他描述 1.需求规格说明书 2. 编制需求分析阶段的文档 软件需求说明书 数据要求说明书 初步的用户手册 修改、完善与确定软件开发实施计划 需求说明书由以下几部分组成： 一套分层的数据流图 一本数据字典 一组小说明 补充材料 常用的分析方法 面向数据流 的结构化分析方法 (SA) 面向数据结构 的 Jackson方法 (JSD) 面向对象 的分析方法 (OOA) 等 3.5 结构化分析方法 (Structured Analisys, SA) 结构化分析就是使用 DFD,DD,结构化语言，判 定表和判定树等工具，来建立一种新的，称为结构 化说明书的目标文档。 结构化分析的基本步骤 ： 由顶向下对系统进行功能分解，画出分层 DF图； 由后向前定义系统的数据和加工，编制 DD， PSPEC; 最终写出 SRS. 结构化分析方法使用工具： 数据流图 数据词典 结构化英语 判定表与判定树 描述银行取款过程的数据流图 画分层数据流图 软件工程技术中，控制复杂性的两个基本手段是“分解” 和“抽象”。 分解？ 为了将复杂性降低到人可以掌握的程度，可以把大问题 分割成若干个问题，然后分别解决。 抽象？ 分解也可以分层进行，即先考虑问题最本质的属性， 暂把细节略去，以后再逐层添加细节，直至涉及到最 详细的内容。 DFD可以用来表示一个系统或软件在任何层次 上的抽象。 较大型软件系统 DFD分成多层 (子图、 父图概念 ),可以表示数据流和功能的进一步的细节。 数据流图的层次结构 为了表达数据处理过程的数据加工情况，需要采用 层次 结构 的数据流图。按照系统的层次结构进行 逐步分解 ，并以 分层的数据流图反映这种结构关系，能清楚地表达和容易理 解整个系统。 分层的数据流图 在多层数据流图中， 顶层流图 仅包含 一个加工 ，它代 表被开发系统。它的输入流是该系统的输入数据，输 出流是系统所输出数据 底层流图 是指其 加工不需再做分解 的数据流图，它处 在最底层 中间层流图 则表示 对其上层父图的细化 。它的每一加 工可能继续细化，形成子图。 结构化分析方法步骤示例 商店业务处理系统 这个数据流图只是一个高层的系统逻辑模型，它反映 了目标系统要实现的功能 数据流图绘制步骤 首先确定系统的输入和输出 根据商店业务，画出顶层数据流图，以反映最主要 业务处理流程 经过分析，商店业务处理的 主要功能 应当有 销售 、 采购 、 会计 三大项。 主要数据流输入的源点 和 输 出终点 是 顾客 和 供应商 。 然后从输入端开始，根据商店业务工作流程，画 出数据流流经的各加工框，逐步画到输出端，得 到第一层数据流图 第一层数据流图 加细每一个加工框 销售细化 采购细化 需求分析示例 教材购销管理系统（ 1） 问题描述：学校教材科根据业务的需要，建 立一个学校教材购销管理系统，提高教材采 购、销售和信息管理的效率。 学 生 张秘书 购书 申请 王会计 李出纳 赵保管 学 生 购书 证明 购书 申请 购书 申请 书 学 生 审 查 有效性 购书 单 开发票 开领 书单 发 书 学 生 有 效 购书单 发票 领书 单 书 学 生 审查并 开发票 购书 单 开领 书单 发书 学 生 发票 领书单 书 2）去掉具体模型中的非 本质因素，抽象出当前 系统的逻辑模型 1）通过对现实环境的调查研究，获 得当前系统的具体模型 3）分析当前系统与目标 系统的差别，建立目标 系统的逻辑模型。 需求分析示例 教材购销管理系统（ 2） 学 生 审查并 开发票 购书单 开领 书单 学 生 发票 领书单 无效书单 4）对目标系统进行补充 和完善，并写出完整的 需求说明。 学 生 1 审查并 开发票 购书单 2 开领 书单 学 生 发票 领书单 无效书单 各班学生用书表 教材存量表 5）对需求说明进行复审， 直到确认文档齐全，并 且符合用户的全部需求 为止 需求分析示例 教材购销管理系统（ 3） 学生 教材购销管理系统 书 库保管员 1. 教材购销管理系统的顶层 DFD 学生 书 库 保管员 2. 第二层 DFD图 教材购销系统 购书单 领书单 缺书单 进书通知 购书单 领书单 1 销 售 2 采购 进书通知 F2: 缺书登记表 F1: 教材存量表 缺书单 进书通知 需求分析示例 教材购销管理系统（ 4） 1.1 审 查 有效性 1.2 开发票 有效 购书单 1.3 领书并 开领书单 发票 1.4 登记 缺书 1.5 补售 教材 F2: 缺书登记表 学生 学生 无效书单 领书单 领书单 F3: 各班学生用书表 F4: 售书登记表 补售 书单 暂缺书单 采购 3. 第三层 DFD图 销售子系统 F1: 教材存量表 需求分析示例 教材购销管理系统（ 5） 2.3 修改教材库 存和待购量 2.1 按 书 号 汇总缺书 F2: 缺书登记表 销售 子系统 书库 保管员 F1: 教材存量表 进书通知 3. 第三层 DFD图 采购子系统 2.2 按出版社 统计缺书 F5: 待购教材表 F6: 教材一览表 进书通知 需求分析示例 教材购销管理系统（ 6） 数据字典（ Data Directory-DD) 领书单 = 学院 +专业 +班级 +学号 +姓名 +书号 +书名 +数量 +日期 有效购书单 = 领书单 发票 = 学号 +姓名 +书号 +书名 +单价 +数量 +总价 +书费合计 教材存量表 = 书号 +单价 +数量 暂缺书单 = 学号 +姓名 + 书号 +数量 补售书单 = 学号 +姓名 + 书号 +数量 书 号 书 名 数 量 书 号 书 名 数 量 学院： 专业： 班级： 学号： 姓名： 武汉科技大学教材科领书单 20 年 月 日 书号 书名 单价 数量 金额 备注 学号： 姓名： 发 票 人事工资管理系统的顶层 DFD(概图 )范例 人 事 部 门 人事工资 管理系统 会 计 部 门 职 工 职工基本 信息管理 子系统 1.0 2.0 人事工资管理系统 0层 DFD范例 职工出缺勤信息 职工工资管理 子系统 3.0 职工出缺 勤管理 子系统 职工基本信息 职工工资信息 人 事 部 门 会 计 部 门 职 工 建立职工 出缺勤信息 3.1 人事工资管理系统 1层 DFD：加工 3.0的分解图 职工出缺勤信息 3.2 制作职工出缺 勤信息 统计表 职工基本信息 实例 考务处理系统功能 (1)对考生送来的报名单进行检查； (2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总 后的考生名单送给阅卷站； (3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格 标准审定合格者； (4)制作考生通知单 (含成绩及合格 /不合格标志 )送给考生； (5)按地区进行成绩分类统计和试题难度分析，产生统计分析表。 顶层数据流图 考 生 考务 处理系统 考 试 中 心 阅卷站 不合格报名单 报名单 准考证 考生通知单 成 绩 清 单 合格标准 错误成绩 清单 考 生 名 单 统计分析表 二层 数据流 图 登记 报名单 报名单 准考证 1 统计成绩 2 不合格 报名单 考生通知 单 成 统计分析 表 考生名册 绩 清 单 合 格 标 准 考 生 名 单 成 绩 清 单 错 误 三层数据流图 (a) 检查 报名单 报名单 准考证 1.1 编准考证号 1.2 不合格 报名单 考生名册 考生名单 合格 报名单 登记 考生 1.3 三层数据流图 (b) 检查 成绩清单 2.1 审定 合格者 2.2 考生名册 正确 成绩清单 制作 通知单 2.3 分析 统计成绩 2.4 分析 试题难度 2.5 试题得分清单 考生 通知单 难度 分析表 合格 标准 分类 统计表 成绩清单 错误 成绩清单 经审定的 成绩清单 检查和修改数据流图的原则 数据流图上所有图形符号 只限于 前述四种基本图形元 素； 数据流图的 主图必须包括前述四种基本元素 ，缺一不 可； 数据流图的主图上的数据流必须封闭在外部实体之间； 每个加工 至少有一个输入数据流和一个输出数据流； 在数据流图中，需 按层给加工框编号 。编号表明该加 工所处层次及上下层的亲子关系； 规定任何一个数据流子图必须与它上一层的一个加工 对应，两者的输入数据流和输出数据流必须一致。此 即 父图与子图的平衡； 可以在数据流图中加入物质流，帮助用户理解数据流 图； 图上每个元素都必须有名字； 数据流图中不可夹带控制流； 初画时可以忽略琐碎的细节，以集中精力于主要数据流。 画分层 DFD的指导原则 (1) 父图与子图的 平衡 模型细化时必须保持数据流的连 续性，即每个细化部分的输入和输出 必须保持不变 (父图和子图输入数据 和输出数据应一致 )。 父图与子图平衡的特例 领 书 单 1.3 发票 1.3.3 1.3.2 教材 1.3.1 学生 领 书 单 父图 子图 发票学生教材 (2) 区分局部文件和局部外部项 .1 .2 .3 1 父图 子图 画分层 DFD的指导原则 (3) 遵守加工的编号原则 子图的编号为父图中相应加工的编号； 子图中加工的编号由子图号、小数点、局部号连接而成。 画分层 DFD的指导原则 画分层 DFD的指导原则 (4) 分解的深度与层次 按功能情况定，一般设深度为 3-5。 原则： 分解应自然，概念上合理、清晰； 只要不影响数据流图的“易理解性”，可以适当地多分解成几部分，这样 分层土的层数就可少些； 一般说来，在上层可以分解的快些，而在下层则应分解的慢些，因为上层 是一些综合性的描述，“易理解性”相对地说不太重要。 实例：运动会管理系统 过程如下： 首先决定日期、地点规模设立那些比赛项目、报名 期限等，并作出一些规定，如每人最多可参加多少项 目，每个项目每队最多可有多少人参加等。在报名结 束后，要给每个运动员编号，统计每个项目有多少运 动员以及有哪些运动员参加，并根据每个项目的参加 人数等具体情况派出比赛日程表。在运动会进行过程 中要按各项比赛的成绩及时公布单项名次并累计团体 总分。比赛全部结束后要公布团体名次。 3.6 面向对象分析方法 思考题 软件开发中为什么要使用面向对象 方法？ 面向对象分析方法与结构化分析方 法有哪些相似之处？有何区别？ 面向对象方法是对过去的一个完全 突破，还是“换汤不换药”？ 开发方法的组合 分析 设计 编程 结构化 结构化 面向对象 结构化 面向对象 面向对象 面向对象 结构化 第三代或第四代语言 面向对象 面向对象 第三代或第四代语言 面向对象 面向对象 传统编程与面向对象的混合 面向对象 面向对象 面向对象 传统方法数据与过程是分离的 过程 1 输入 输出 过程 2 过程 3 数据实体 属于该对象 的数据 对象 处理数据的方法 消息 消息 对象把数据和处理数据的方法封装成一个单元 传统方法和面向对象方法的比较 传统方法 系统是过程的集合 过程与数据实体交互 过程接受输入并产生输出 面向对象方法 系统是交互对象的集合 对象与人或其它对象交互 对象发送与响应消息 传统系统分析方法 :面向功能 ,把系统看成一组功能； OOA方法 :把问题当作一组相互作用的实体，并确定实体 间关系。 传统方法和面向对象方法的比较 结构化分析 (传统建模方法 )方法 分析模型： 数据流图 (DFD) 数据字典 (DD) 小说明 E-R图 (ERD) 状态变迁图 (STD) 面向对象分析方法 分析模型： 用例模型（用况模型） 对象模型（概念模型） 功能模型（行为模型） 分析建模方法与分析模型 分析模型的主要目标 描述用户需要 建立创建软件设计的基础 定义软件完成后可被确认的一组需求 OO方法的开发过程 OO方法改进了在生存期各个阶段间的界面 ， 因为生存期各个阶段开发出来的 “ 部件 ” 都是 类 ， 在面向对象生存期的各个阶段对各个 类 的信息进 行细化 ， 类 成为分析 、 设计和实现的 基本单元 。 用例建模 用例建模是用于描述一个系统应该做什么的建模技术； 用例建模可用于新系统的需求获取，也可用于已有系 统的升级。 发现角色（ P61） 通过回答下列问题，可以帮助建模者发现角色 使用系统主要功能的人是谁？ 需要借助于系统完成日常工作的人是谁？ 谁来维护、管理系统，保证系统正常工作？ 系统控制的硬件设备有哪些？ 系统需要与哪些其它系统交互？ 对系统产生的结果感兴趣的人或事是哪些？ 发现用例（ P61） 询问以下问题 角色需要从系统中获得哪种功能？角色需要做什么？ 角色需要读取、产生、删除、修改或存储系统中的信息吗？ 系统中发生的事件需要通知角色吗？ 如果用系统的新功能处理角色的日常工作是简化了还是提 高了工作效率？ 用例模型（ use case model） 一个用例模型可由若干幅用例图组成 用例描述了用户和系统之间的交互，其重点是系 统为用户做什么 用例模型描述全部的 系统功能行为 一幅用例图包含的模型元素有： 用例 参与者（行为者、执行者） 系统 用例 参与者 系统 参与者 通信 关系 用例模型 用例图举例 签定一份 保险单 客户 保险销 售人员 销售统计 客户统计 2.领域分析 目的：发现或创建一些可广泛应用的类，使它们可以被复用。 具体地说，面向对象领域分析就是以公共对象、类、子集合和框架等形 式，在特定的应用领域中表示、分析和规约公共的可复用的能力。举 例： （ P63） 领域分析的输入输出 领域知识源 领域分析 领域分析 -创建可以广泛地用于整个应用领域范畴的可复用类 (构件 ) 航空 银行 电子设备 多媒体视频 领域 分析 领域 分析 模型 技术文件 已有应用 客户评定 专家建议 需求 提取类 复用标准 模型 语言 领域分析活动： 定义被调查的领域，相关的设计、规约、代码、政策、标准、规程等项 对领域中提取的项，划分种类并提取模式，命名，并且分层。 收集领域中应用的代表性样本 分析每个样本中的应用，标识对象、说明理由、定义适应性、估算复用率等 开发对象分析模型，作为设计和构造类的基础 3.类 /对象建模 系统的用例一旦确定，即可开始标识类 对象。 考察系统的使用实例，首先将这些实例中的名词 或名词短语汇总起来，得到候选对象；然后考察这些对象的特征， 进而确定哪些对象应该包含在分析模型中。举例： （ P64） 对象模型 是三个模型中最关键的一个模型 ， 它的作用是 描述系 统的静态结构 ， 包括 构成系统的类和对象 ， 它们的属 性和操作 ， 及 它们之间的关系 。 确定需求分析模型中的类 /对象 对象（ object) 现实世界中某个具体的物理实体或概念在计算机 逻辑中的映射和体现。 对象具有的含义： 在现实世界中： 是客观世界中的一个实体 在面向对象程序中： 表达成计算机可理解、可操纵的对象 在计算机世界中： 是一个可标识的存储区域 识别概念 候选概念类型 举例 物理的或实在的对象 POS机 飞机 规格说明、设计或事物 描述 产品规格说明 航班描述 地点 商店 机场 事务 销售、支付、在线销售项 预定 人的角色 出纳员 飞行员、乘客 系统外部的其他系统或 设备 信用卡授权系统 空中交通控制系统 组织 销售部 建立概念模型（ UML中的类图） 确定并定义类 建立关联 添加属性 描述系统行为：系统顺序图等 类及对象间常见的联系 分类关系 （归纳关系、一般与特殊的关系） 组成关系 （组合关系、整体 /部分的关系） 对象属性之间的静态的联系 对象行为的动态联系 定义类的结构与层次 分类关系 (一般与特殊的关系 )示例 学生 本科生 研究生 分类结构（一般 /特殊结构） 分类是对象抽象的基础 分类结构表现的是事物的一般与特殊的关系，即“ is-a” 关系。 面向对象术语中常把一般与特殊的关系称为 泛化 （ Generalization） 与 特化（ Specialization） 联系 存户 一般 /特殊结构举例 一般类 (父类、基类、超类 ) 特殊类 (子类、具体类 ) 继承 一个特殊类中的所有对象可继承一般类中的属性、服 务、关系 账号 姓名 余额 存款 取款 支票存户 储蓄存户 利息率 组成关系 (整体与部分的关系 )示例 学科部 办公室