UML_第五章_UML核心模型[1].ppt

1、第五章 UML核心模型,5.1 用例模型概述 5.2 业务用例模型 5.3 概念用例模型 5.4 系统用例模型 5.5 领域模型 5.6 分析模型 5.7 软件架构和框架 5.8 设计模型 5.9 组件模型,三种模型及关系,三种模型：类模型、状态模型、交互模型 典型的软件过程合并了所有这三个方面：它使用数据结构（类模型），按时间设定操作顺序（状态模型），并在对象之间传递数据和控制（交互模型）。 每种模型都包含了对其他模型中的实体的引用。,类模型,类模型描述系统中对象的结构-它们的标识、与其他对象的关系、属性和操作。 类模型提供了状态和交互模型的上下文。 类图表达了类模型。泛化使得类可以共享结构

2、和行为，关联使得类之间发生关系。,状态模型,状态模型描述了与操作的时间和顺序相关的对象层面标记变化的事件，界定时间上下文的状态，以及时间和状态的组织。 状态模型捕获控制，即描述操作出现顺序的系统层面，不考虑操作做了些什么，他们在操作什么。 状态图表示状态模型。,交互模型,交互模型描述对象之间的交互独立对象如何协作，来从整体上完成系统的行为。 状态和交互模型描述了行为的不同侧面。 用例、顺序图和活动图描述交互模型。,模型间的关系,类模型描述状态模型和交互模型操作的数据结构。 状态模型描述对象的控制结构 交互模型专注于对象之间的信息互换，并提供了系统操作的整体视图。,本章主要介绍RUP软件工程思想

3、。,5.1 用例模型概述(I),用例模型在RUP中占据十分重要的地位： 它是面向对象软件过程的骨架开发过程中一切工作的组织框架； 它是面向对象软件过程的神经系统用例驱动过程 它是面向对象软件过程的血肉需求的来源，测试的依据,5.1 用例模型概述(II),用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。 用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。,5.1 用例模型概述(III),5.1 用例模型概述(III),三个不同抽象层次的用例模型的关系,5.2 业务用例模型(I),建立业务用例模型原因： 因为业务用例模型的目的是为现存的或

4、客户预想中的真实业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型。 业务用例模型要准确而完备地描述客户的现存或预想业务，而系统用例模型则可能只是业务的片段或者部分。,5.2 业务用例模型(II),业务用例模型描述的是业务范围，与系统用例模型讲述的系统范围是不同的。,5.2 业务用例模型(III),完整的业务用例模型,5.2.1 业务用例模型主要内容,业务用例视图 业务用例场景 业务用例规约 业务规则 业务对象模型 业务用例实现视图 业务用例实现场景 包图,5.2.2 业务用例模型工件的取舍(I),业务主角 业务构架文档 业务实体 业务词汇表 业务对象模型 业务规

5、则 业务用例 业务用例模型,5.2.2 业务用例模型工件的取舍(II),业务用例实现 业务前景 业务角色 组织单元 补充业务规约 目标组织评估,5.2.3 何时使用业务用例模型(I),使用业务用例模型的理由 开发一个针对商业组织的软件 开发一个交互密集型软件 开发一个较大规模的软件 面对的问题领域有复杂的组织结构 所面对的业务有许多业务流程 客户希望借信息化过程进行业务重组或优化 你对这个行业了解不多，希望首先对业务有清楚的认识。 希望借由一个软件开发而打入一个行业应用软件市场 虽然对这个行业了如指掌，但希望做行业标准，因而想建立业务架构 客户已有许多孤立的遗留系统，希望做应用整合。,5.2.

6、3 何时使用业务用例模型(II),不使用业务用例模型的理由： 将开发一个非商业组织应用软件，如嵌入式系统 将开发一个计算密集型软件，如编码解码器 将开发的软件规模很小 所面对的问题领域组织结构单一 所面对的问题领域没有或仅有很简单的业务流程，如论坛系统 客户的信息系统已经非常成熟，只想做一些外围的小应用 对行业业务十分精通，想要快速和低成本项目，不打算做行业标准 虽然对业务不大了解，不打算在该行业深入下去,5.3 概念用例模型,概念用例模型位于先启阶段，有时在精华阶段进行，是业务用例建模的一个子集。,5.3.1 概念用例模型的主要内容,概念用例视图 概念用例分析 分析类视图 分析场景,5.3.

7、2 获得概念用例,获取概念用例的主要途径： 观察现有的业务用例场景，发现在不同业务用例场景中相似名称、多次出现、位于不同泳道中的活动 通过对客户业务的分析，得知对客户来说最为重要的一些业务实体。然后了解对这些业务实体可能进行的主要操作来获得备选的概念用例。 通过对客户业务流程的分析，得知客户最为关心的、影响整个流程成败的关键业务环节，备选概念用例 通过绘制概念用例分析来检验备选的概念用例。,5.3.3 何时使用概念用例模型,使用概念用例的理由： 所面对的业务领域规模庞大，业务用例粒度较大，不容易过渡到较小的系统用例 所面对的业务领域业务是网状交叉的，有夸业务用例的业务流程存在 某个业务场景过于

8、复杂，步骤和分支过多 有超过7、8个的泳道存在 想在项目早期就获得系统原型 想在项目早期就开始建立软件架构 第一次开发这样的系统，对系统用例的决定有疑问。,5.3.3 何时使用概念用例模型,不使用概念用列理由： 所面对的业务领域规模较小，业务用例粒度较小，容易过渡到系统用例 所面对的业务领域较为单纯，基本上没有交叉业务 业务用例场景简单，不超过10个步骤 不打算太早建立软件架构 对该系统很熟悉。,5.4 系统用例模型,用例模型定义为系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条诛仙。 系统功能型需求完全由用例模型来表达。 用例模型是客户理解系统的

9、最重要图形。,5.4 系统用例模型,5.4.1 系统用例模型的主要内容,业务用例 概念用例 用例视图 用例规约 补充规约 业务规则 用例实现 用例场景 分析对象,5.4.2 获得系统用例,如果已经建立了业务用例，就可以从业务用例中导出系统用例。 推导系统用例的基本方法是分析业务用例场景，尤其是活动图。系统用例可以从这些职责中抽取出来。然后考虑以下问题： 排除用例 合并用例 抽象用例 补充用例 系统用例的粒度应当与概念用例相当 系统用例的抽象角度应当与概念用例相当 概念用例所表述出的核心业务是最需要关心的部分,5.5 领域模型,领域模型用来对问题域中某个问题来建立对象模型，它代表系统工作环境中存

10、在的事情或发生的事件。 领域类有三种典型的形式： 业务对象，表示业务中使用到或产生的东西 系统需要处理的现实世界中的对象或概念 将要发生或已经发生的事件,5.5 领域模型,领域模型可以帮助我们理解问题领域中的关键概念和关键对象，帮助理解这些对象是如何工作，以及如何解决问题。 建立和验证领域模型可以使用CRC方法。 领域模型 为非交互密集型的软件建立领域模型(参与者少，用例意义不大) 为交互密集型的软件中交叉和重叠的对象建立领域模型,5.5 领域模型,5.6 分析模型,分析类用于获取系统中主要的“职责簇”。 分析类应成为面向对象设计的核心，因为： 分析模型是采用分析类在软件架构和框架的约束下来实

11、现用例场景的产物。 分析模型是高层次的系统视图， 设计模型是分析模型的一种实现手段。 分析模型是MVC模式的经典应用。,5.6 分析模型,由于分析类忽略了实现细节，可以只关心系统如何使用对象来实现需求。采用分析类来维护系统实现与需求的同步能节省大量工作量。因为： 设计模型由于考虑太多的实现细节，保持设计模型与需求同步是困难的 从用例场景到设计模型的跨度太大，设计类如何决定更多是凭经验,5.6.1 如何使用分析模型,获取分析类的方法，先采用时序图，在用例场景中的参与者与系统之间加入一个边界类代表操作界面，在边界类与实体交互之间加入了一个控制类代表业务逻辑，然后对照用例场景，把用例场景过程用分析类

12、实现出来。 先绘制用例实现的时序图是获得分析类的一种有效方法。,5.6.1 如何使用分析模型,由于分析类采用了MVC模式，所以在定义分析类之间关系的时候，应当注意以下几个原则： 边界类不应当与实体类之间有依赖关系，边界类只能通过控制类与实体类交互。 实体类和实体类之间可以有聚合或组合关系，但不应当有依赖关系。他们不应当直接交互，而只能通过控制类间接交互 控制类和控制类之间不应当有聚合或组合关系，应尽量减少依赖关系 正确的依赖关系应当是边界类依赖于控制类，控制类依赖于实体类。,5.6.1 如何使用分析模型,定义了备选的分析类的关系以后，调整分析类主要原因和手段来自以下几个方面： 业务规则 结构优

13、化 分离职责,5.6.1 如何使用分析模型,5.6.1 如何使用分析模型,5.6.2 分析模型的主要内容,5.6.3 分析模型的意义,分析模型采用MVC模式，将用例场景中描述的业务分解为边界、控制和实体，用这三个元素建立实现用例场景的对象模型。 某些分析类变为设计类，其他分析类变为设计子系统。分析的目标是确定一种从所需行为到系统中建模元素的初步映射。设计的目标是将此初步映射转换成可实施的模型元素集。,5.6.3 分析模型的意义,决定是否需要单独的分析模型时应考虑以下几点： 需要设计在多目标环境下使用、带有独立设计架构的系统时，独立的分析模型就非常有用。 由于设计的复杂，向新团队成员介绍设计时需

14、要使用简化而抽象的设计 在考虑建立分析模型所带来的益处时，必须权衡为确保分析模型与设计模型保持一致性所需的额外工作，因为该模型只代表系统的最重要的细节 一旦不再为分析模型进行维护，其价值将迅速衰减。,5.7 软件架构,架构是系统蓝图，是对系统高层次的定义和描述。框架是解决方案。,5.7.1 软件架构,5.7.1.1 业务架构 5.7.1.2 软件架构 5.7.1.3 架构描述,5.7.1.2 软件框架-广度视角,5.7.1.2 软件框架-深度视角,5.7.1.3 架构描述,业务架构概述 组织结构 业务模块 业务对象模型 典型用例场景 软件架构概要 计算环境 软件层次 实现架构 协议和接口 软件

15、框架 典型用例场景的架构实现 非功能需求,5.7.2 软件框架,5.8 设计模型,设计模型是一个描述用例实现的对象模型，它可作为对实施模型及其源代码的抽象。设计模型用作实施和测试活动的基本输入。 设计模型是编码实现之前的最后一道建模工序。,5.8 设计模型,5.8.1 设计模型的应用场合,设计模型在软件架构、框架和典型场景下有着很大的作用。 软件架构场合 软件框架场合 典型场景场合,5.8.2 设计模型的主要内容,5.8.2 设计模型的主要内容-推荐的设计模型用法,5.8.3 从分析模型映射到设计模型,实现分析角色的可能方法： 一个分析类可以成为设计模型中的单个类 一个分析类可以成为设计模型中某个类的一部分 一个分析类可以成为设计模型中的一个聚合关系类 一个分析类可以成为设计模型中从同一个类继承而来的一组类 一个分析类可以成为设计模型中一组功能相关的类,5.8.3 从分析模型映射到设计模型,实现分析角色的可能方法： 一个分析类可以成为设计模型中的一个包 一个分析类可以成为设计模型中的一项关系 一个分析类可以成为设计模型中的一个类 分析类之间的一项关系可以成为设计模型中的一个类 分析类主要处理功能性需求以及来自“问题”领域的模型对象；设计类则处理非功能性需求以及来自“解决方案”领域的模型对象 分析类可用来代表“希望系统支持的对象”,5.9 组件模型,组件四