UML第五章UML核心模型.ppt

结构和行为，关联使得类之间发生关系。
状态模型
▪ 状态模型描述了与操作的时间和顺序相关 的对象层面—标记变化的事件，界定时间 上下文的状态，以及时间和状态的组织。
▪ 状态模型捕获控制，即描述操作出现顺序 的系统层面，不考虑操作做了些什么，他 们在操作什么。
▪ 状态图表示状态模型。
交互模型
▪ 交互模型描述对象之间的交互—独立对象 如何协作，来从整体上完成系统的行为。
5.2.3 何时使用业务用例模型(I)
▪ 使用业务用例模型的理由
➢ 开发一个针对商业组织的软件 ➢ 开发一个交互密集型软件 ➢ 开发一个较大规模的软件 ➢ 面对的问题领域有复杂的组织结构 ➢ 所面对的业务有许多业务流程 ➢ 客户希望借信息化过程进行业务重组或优化 ➢ 你对这个行业了解不多，希望首先对业务有清楚的认
▪ 概念用例视图 ▪ 概念用例分析 ▪ 分析类视图 ▪ 分析场景
5.3.2 获得概念用例
▪ 获取概念用例的主要途径：
➢ 观察现有的业务用例场景，发现在不同业务用 例场景中相似名称、多次出现、位于不同泳道 中的活动
➢ 通过对客户业务的分析，得知对客户来说最为 重要的一些业务实体。然后了解对这些业务实 体可能进行的主要操作来获得备选的概念用例。
➢ 业务用例模型要准确而完备地描述客户的现存 或预想业务，而系统用例模型则可能只是业务 的片段或者部分。
5.2 业务用例模型(II)
▪ 业务用例模型描述的是业务范围，与系统 用例模型讲述的系统范围是不同的。
5.2 业务用例模型(III)
▪ 完整的业务用例模型
5.2.1 业务用例模型主要内容
▪ 业务用例视图 ▪ 业务用例场景 ▪ 业务用例规约 ▪ 业务规则 ▪ 业务对象模型 ▪ 业务用例实现视图 ▪ 业务用例实现场景 ▪ 包图
➢ 所面对的业务领域较为单纯，基本上没有交叉 业务
➢ 业务用例场景简单，不超过10个步骤 ➢ 不打算太早建立软件架构 ➢ 对该系统很熟悉。
5.4 系统用例模型
➢ 通过对客户业务流程的分析，得知客户最为关 心的、影响整个流程成败的关键业务环节，备 选概念用例
➢ 通过绘制概念用例分析来检验备选的概念用例。
5.3.3 何时使用概念用例模型
▪ 使用概念用例的理由：
➢ 所面对的业务领域规模庞大，业务用例粒度较 大，不容易过渡到较小的系统用例
➢ 所面对的业务领域业务是网状交叉的，有夸业 务用例的业务流程存在
识。 ➢ 希望借由一个软件开发而打入一个行业应用软件市场 ➢ 虽然对这个行业了如指掌，但希望做行业标准，因而
想建立业务架构 ➢ 客户已有许多孤立的遗留系统，希望做应用整合。
5.2.3 何时使用业务用例模型(II)
▪ 不使用业务用例模型的理由：
➢ 将开发一个非商业组织应用软件，如嵌入式系统 ➢ 将开发一个计算密集型软件，如编码解码器 ➢ 将开发的软件规模很小 ➢ 所面对的问题领域组织结构单一 ➢ 所面对的问题领域没有或仅有很简单的业务流程，如
5.2.2 业务用例模型工件的取舍(I)
▪ 业务主角 ▪ 业务构架文档 ▪ 业务实体 ▪ 业务词汇表 ▪ 业务对象模型 ▪ 业务规则 ▪ 业务用例 ▪ 业务用例模型
5.2.2 业务用例模型工件的取舍(II)
▪ 业务用例实现 ▪ 业务前景 ▪ 业务角色 ▪ 组织单元 ▪ 补充业务规约 ▪ 目标组织评估
第五章 UML核心模型
5.1 用例模型概述 5.2 业务用例模型 5.3 概念用例模型 5.4 系统用例模型 5.5 领域模型 5.6 分析模型 5.7 软件架构和框架 5.8 设计模型 5.9 组件模型
三种模型及关系
▪ 三种模型：类模型、状态模型、交互模型 ▪ 典型的软件过程合并了所有这三个方面：
➢ 某个业务场景过于复杂，步骤和分支过多 ➢ 有超过7、8个的泳道存在 ➢ 想在项目早期就获得系统原型 ➢ 想在项目早期就开始建立软件架构 ➢ 第一次开发这样的系统，对系统用例的决定有
疑问。
5.3.3 何时使用概念用例模型
▪ 不使用概念用列理由：
➢ 所面对的业务领域规模较小，业务用例粒度较 小，容易过渡到系统用例
论坛系统 ➢ 客户的信息系统已经非常成熟，只想做一些外围的小
应用 ➢ 对行业业务十分精通，想要快速和低成本项目，不打
算做行业标准 ➢ 虽然对业务不大了解，不打算在该行业深入下去
5.3 概念用例模型
▪ 概念用 例模型 位于先 启阶段， 有时在 精华阶 段进行， 是业务 用例建 模的一 个子集。
5.3.1 概念用例模型的主要内容
▪ 状态和交互模型描述了行为的不同侧面。 ▪ 用例、顺序图和活动图描述交互模型。
模型间的关系
▪ 类模型描述状态模型和交互模型操作的数 据结构。
▪ 状态模型描述对象的控制结构 ▪ 交互模型专注于对象之间的信息互换，并
提供了系统操作的整体视图。
▪ 本章主要介绍RUP软件工程思想。
5.1 用例模Biblioteka 概述(I)▪ 用例模型在RUP中占据十分重要的地位：
➢ 它是面向对象软件过程的骨架—开发过程中一 切工作的组织框架；
➢ 它是面向对象软件过程的神经系统—用例驱动 过程
➢ 它是面向对象软件过程的血肉—需求的来源， 测试的依据
5.1 用例模型概述(II)
▪ 用例模型是系统既定功能及系统环境的模 型，它可以作为客户和开发人员之间的契 约。
它使用数据结构（类模型），按时间设定 操作顺序（状态模型），并在对象之间传 递数据和控制（交互模型）。 ▪ 每种模型都包含了对其他模型中的实体的 引用。
类模型
▪ 类模型描述系统中对象的结构-它们的标识、 与其他对象的关系、属性和操作。
▪ 类模型提供了状态和交互模型的上下文。 ▪ 类图表达了类模型。泛化使得类可以共享
▪ 用例模型即为需求工作流程的结果，可当 作分析设计工作流程以及测试工作流程的 输入使用。
5.1 用例模型概述(III)
5.1 用例模型概述(III)
▪ 三个不同抽象层次的用例模型的关系
5.2 业务用例模型(I)
▪ 建立业务用例模型原因：
➢ 因为业务用例模型的目的是为现存的或客户预 想中的真实业务建立模型，是我们为了理解客 户的业务，并与客户达成业务理解上的共识而 建立的模型。