构建分析模型.ppt

软件工程 第7章构建分析模型 主要内容 需求分析分析建模的方法数据建模概念面向对象的分析基于场景建模面向流的建模基于类的建模生成行为模型小结 分析模型 文字记录是极好的交流工具 但并不必然是表达计算机软件需求的最好方式 分析建模使用文字和图表的综合形式 以相对容易理解的方式描绘需求的数据 功能和行为 更重要的是 可以更直接地评审它们的正确性 完整性和一致性 软件工程师使用从客户那里提取的需求构建模型 分析模型 可以使用很多不同格式的图表为信息 功能和行为需求建模 基于场景的建模从用户的角度表现系统 面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示 基于类的建模定义了对象 属性和关系 行为建模描述了系统状态 类和事件在这些类上的影响 一旦创建了模型的雏形 就将不断改进 并分析评估其清晰性 完整性和一致性 最终的分析模型将由所有的共利益者确认 分析模型 必须评审分析建模工作产品的正确性 完整性和一致性 必须反映所有共利益者的要求并建立一个可以从中导出设计的基础 分析模型 在技术层面上 软件工程开始于一系列的建模工作 最终生成待开发软件的需求规格说明和全面的设计表示 分析模型实际上是一组模型 是系统的第一个技术表示 分析阶段的目标 DEM79 分析的结果必须是高度可维护的 尤其是要将此结果应用于目标文档 必须使用一种有效的分割方法解决规模问题 尽可能使用图形符号 考虑问题必须区分逻辑的和物理的 需求分析 需求分析产生软件操作特征的规格说明 指明软件和其他系统元素的接口 建立软件必须满足的约束 需求分析让软件工程师细化在前期需求工程工作中建立的基础需求 并建立模型描述用户场景 功能活动 问题类和类之间的关系 系统和类行为以及数据流 需求分析 在整个分析建模过程中 软件工程师的主要关注点集中在 做什么 而不是 怎么做 方面 包括 系统处理什么对象 系统必须执行什么功能 系统显示什么行为 定义什么接口 有什么约束 整体目标和原理 分析模型必须实现三个主要目标 描述客户需要什么 为软件设计奠定基础 定义在软件完成后可以被确认的一组需求 分析模型在系统级描述和软件设计的差距之间建立桥梁 重要的是要注意到在系统描述中给出分析模型的某些元素 并且需求工程的工作实际上是作为系统工程的一部分开始的 此外 分析模型的所有元素都可以直接跟踪到设计模型 通常难以区分这两个重要的建模活动之间的设计和分析工作 有些设计总是作为分析的一部分进行 而有些分析将在设计中进行 分析模型在系统描述和设计模型之间建立桥梁 图7 1分析模型在系统描述和设计模型之间建立桥梁 分析的经验原则 ARL02 模型应关注在问题域或业务域内可见的需求 抽象的级别应该相对高一些 分析模型的每个元素都应能增加对软件需求的整体理解 并提供对信息域 功能和系统行为的深入理解 关于基础结构和其他非功能的模型应推延到设计阶段再考虑 最小化整个系统内的关联 确认分析模型为所有共利益者都带来价值 尽可能保持模型简洁 域分析 分析模型通常在特定业务领域内的很多应用中重复发生 如果用一种方式对这些模式加以定义和分类 让软件工程师或分析师识别并复用这些模式 将促进分析模型的创建 更重要的是 应用可复用的设计模式和可执行的软件构件的可能性将显著增加 域分析 软件域分析是识别 分析和详细说明来自某个特定应用领域的公共需求 特别是那些在该应用领域内被多个项目重复使用的 面向对象的域分析 是在某个特定应用领域内 根据通用的对象 类 部件和框架 识别 分析和详细说明公共的 可复用的能力 域分析的目标很简单 就是 查找或创建那些分析类和 或 能够广泛应用的 共有的功能和特点 这样就可以复用 域分析的输入和输出 图7 2域分析的输入和输出 分析建模的方法 一种考虑数据和处理的分析建模方法被称作结构化分析 其中数据作为独立实体转换 数据对象建模定义了对象的属性和关系 操作数据对象的处理建模应表明当数据对象在系统内流动时处理如何转换数据 分析建模的第二种方法称作面向对象的分析 这种方法关注于定义类和影响客户需求的类之间的协作方式 UML和统一过程主要是面向对象的 分析建模的方法 软件团队往往选择一种方法并排斥另一种方法中的所有表示手段 问题不是哪一种方法最好 而是怎么组合这些表示手段才能够为共利益者提供最好的软件需求模型和过渡到软件设计的最有效方法 分析模型将生成如图7 3所示的每个建模元素的派生类 然而 不同项目之间 每个元素的特定内容可能因项目而异 软件团队必须想办法保持模型的简单性 只有那些为模型增加价值的建模元素才能使用 分析模型的元素 图7 3分析模型的元素 数据建模概念 分析建模通常开始于数据建模 软件工程师或分析师需要定义在系统内处理的所有数据对象 数据对象之间的关系以及其他与这些关系相关的信息 数据对象 数据对象是几乎任何必须被软件理解的复合信息的表示 复合信息是指具有若干不同的特征或属性的事物 数据对象可能是外部实体 事物 发生或事件 角色 组织单位 地点或结构 数据对象描述 包括了数据对象及其所有属性 数据对象 数据对象只封装数据 在数据对象内没有对作用于数据的操作的引用 数据可以表示为如图7 4所示的一张表 表头反映了对象的属性 表体表示了数据对象的特定实例 数据对象的表格表示 图7 4数据对象的表格表示 数据属性 数据属性定义了数据对象的性质 可以具有三种不同的特性之一 它们可以用来 为数据对象的实例命名 描述这个实例 建立对另一个表中的另一个实例的引用 另外 必然把一个或多个属性定义为标识符 主键 通过对问题环境的理解可以恰当地确定特定数据对象的一组属性 数据对象和OO类 数据对象定义了一个复合的数据项 也就是说合并一组独立的数据项 属性 并为数据项集合取个名字 数据对象名 一个OO类封装了数据属性但也合并了对这些属性所定义数据进行处理的操作 另外 类的定义暗示了一个作为面向对象软件工程方法一部分的全面的基础设施 类之间通过消息通信 它可以按层次关系组织并为类的实例 对象 提供继承属性 关系 数据对象可以以多种不同的方式互相连接 可以用一组 对象 关系对 来定义有关的关系 图7 5b以图形方式说明了这些对象 关系对 并提供了关于关联方向的重要信息 这一方向信息通常可以减少不确定性或误解 数据对象之间的关系 图7 5数据对象之间的关系 基数和形态 数据建模的基本元素 数据对象 属性和关系 为理解问题的信息域提供了基础 然而 还必须理解与这些基本元素相关的其他元素 就软件工程的目的而言 简单地说对象X与对象Y相关并没有提供足够的信息 我们必须理解对象X的多少次出现和对象Y的多少次出现相关 这引出了被称为基数的数据建模概念 基数和形态 数据模型必须能够表示在一个给定的关系中对象出现的次数 基数是关于一个 对象 的出现次数可以与另一个 对象 的出现次数相关联的规格说明 对于关系的出现 如果没有明确的必要性或关系是可选的 那么关系的形态是0 如果关系必须出现一次 那么形态是1 数据建模 数据建模工具为软件工程师提供表现数据对象 数据对象的特点和数据对象的关系的能力 主要用于大型数据库应用系统和其他信息系统项目 数据建模工具以自动化的方式创建全面的实体 关系图 数据对象字典以及相关模型 面向对象的分析 面向对象的分析 OOA 其目的是定义与即将解决的问题相关的所有类 以及与其相关的关系和行为 为实现这一点 必须完成如下一些工作 1 在客户和软件工程师之间必须对基本的用户需求进行交流 2 必须确定类 即定义属性和方法 3 定义类的层次结构 4 表现对象与对象的关系 对象连接 5 必须为对象行为建模 6 上述1 5的工作步骤重复迭代直至模型完成 面向对象的概念 属性 说明一个类的数值集合 类 封装数据和过程的抽象 这些是说明某些真实世界中的实体的内容和行为所必需的 即类是一组相似对象的概括说明 对象 某个特定类的实例 对象具有类的属性和操作 操作 也称为方法和服务 表现类的某个行为 子类 超类的特化 子类可以从超类继承属性和操作 超类 也称作基类 是一组相关类的泛化 基于场景建模 如果软件工程师了解最终用户 和其他参与者 希望如何与系统交互 软件团队将能够更好地 更准确地刻画系统特征 完成更有针对性的分析和设计模型 使用UML分析建模 将从开发用例 活动图和泳道图形式的场景开始 编写用例 用例捕获信息的产生者 使用者和系统本身之间发生的交互 用例从某个特定参与者的角度用简单易懂的语言说明一个特定的使用场景 但是我们应该知道 1 编写什么 2 写多少 3 编写说明应该多详细 4 如何组织说明 编写用例 两个首要的需求工程工作 起始和导出 提供了开始编写用例所需要的信息 运用需求收集会议 QFD和其他需求工程机制确定共利益者 定义问题的范围 说明整体的操作目标 概述所有已知的功能需求 描述系统将处理的信息 对象 要开始开发用例 应列出特定参与者执行的功能或活动 这些可以从所需系统功能的列表中获得 或通过与客户或最终用户交流获得 或通过评估活动图获得 SafeHome实例 12 编写用例 随着和共利益者更多地交谈 需求收集团队为每个标记的功能开发用例 通常 用例首先用非正式的描述性风格编写 如果需要更正式一些 可以使用类似前一章中提出的某个结构化的形式重新编写同样的用例 SafeHome实例 13 编写用例 描述性用例的一种变形是通过用户活动的顺序序列表现交互 每个活动由声明性的语句表示 SafeHome实例 14 编写用例 这个连续的陈述没有考虑其他可能的交互 这种类型的用例有时被称作主场景 要完整地理解所描述的功能 必需说明可能的交互 主场景中的每个步骤将通过如下提问得到评估 在这一点 参与者能进行一些其他活动吗 在这一点 参与者有没有可能遇到一些错误的情况 在这一点 参与者有没有可能遇到一些其他的行为 如果有 是什么 这些问题的答案导致创建一组次场景 次场景属于原始用例的一部分 但是表现了可供选择的行为 SafeHome实例 15 编写用例 在很多情况下 不需要创建使用场景的图形化表示 但是图形化表示可以促进理解 尤其是当场景比较复杂时 UML为用例提供了图形化表现的能力 图7 6为SafeHome系统的初步用例图 SafeHome系统的初步用例图 图7 6SafeHome系统的初步用例图 开发活动图 UML活动图通过提供特定场景内交互流的图形化表示来补充用例 活动图使用圆角矩形表示一个特定的系统功能 箭头表示通过系统的流 判定菱形表示判定分支 水平线意味着并行发生的活动 ACS DCV功能的活动图如图7 7所示 SafeHome系统ACS DCV功能的活动图 图7 7ACS DCV功能的活动图 泳道图 UML泳道图是活动图的一种有用的变形 可让建模人员表示用例所描述的活动流 同时指示哪个参与者或分析类对活动矩形所描述的活动负责 职责由纵向分割图的并列条形部分表示 就像游泳池中的泳道 ACS DCV功能的泳道图如图7 8所示 SafeHome系统ACS DCV功能的泳道图 图7 8ACS DCV功能的泳道图 面向流的建模 面向流的数据建模至今仍是最广泛使用的分析表达法之一 尽管数据流图及相关的图和信息不是UML的正式组成部分 但是它们可以补充UML图并提供对系统需求和流的补充认识 DFD采取了系统的输入 处理 输出观点 流入软件的数据对象 经由处理元素转换 最后以结果数据对象的形式流出软件 数据对象由带标记的箭头表示 转换由圆圈 也称作泡泡 表示 DFD使用分层的方式表示 即第一个数据流模型从整体上表现系统 随后的数据流图改进环境图 提供每个后续层增加的细节 创建数据流模型 数据流图有助于软件工程师开发信息域的模型 并同时开发功能域的模型 当DFD被改进到非常详细的程度时 分析师同时也就完成了系统功能分解 创建数据流模型 导出数据流图时有一些很有用的简单的指导原则 第 通过把在下一层表示的候选处理过程 数据对象和数据存储分离 开始求精过程 应使用有意义的名称标记所有的箭头和泡泡 当从一个层转到另一个层时要保持信息流连续性 一次精化一个泡泡 Safehome安全功能的DFD如图7 9所示 SafeHome安全功能的DFD图 图7 9SafeHome安全功能的DFD图 创建数据流模型 第0层的DFD现在要扩展到第1层 有个简单而有效的方法是对描述环境层泡泡的叙述进行 语法分析 即将第一次需求收集会议中获得的SafeHome处理叙述中的所有名词与动词分离开来 SafeHome实例 16 创建数据流模型 这里提到的语法分析 开始形成一种模式 动词是SafeHome处理 它们最终将被表示为后来的DFD中的泡泡 名词是外部实体 方框 数据或控制对象 箭头 数据存储 双横线 通过对任何DFD层次中某个泡泡的处理叙述文字进行语法分析 可以产生许多关于如何精化到下一个层次的有用信息 使用这些信息 第1层DF