UML_第五章_UML核心模型教案解析.pptVIP

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