大象：THINKING IN UML 第五章节 UML核心建模.pptVIP

第五章 UML核心模型 主要模型 业务用例模型 概念用例模型 系统用例模型 领域模型 分析模型 软件架构和框架模型 设计模型 组件模型 实施模型 5.1 用例模型 用例模型在RUP中占据十分重要的地位： 它是面向对象软件过程的骨架—开发过程中一切工作的组织框架； 它是面向对象软件过程的神经系统—用例驱动过程 它是面向对象软件过程的血肉—需求的来源，测试的依据 在面向对象软件过程中，用例模型的好坏将决定整个开发过程的好坏 用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。 用例模型在RUP中的地位 不同抽象层次的用例模型的关系 这三种模型分别在软件开发的不同生命周期阶段发生作用，业务模型用于识别和规定业务需求，概念模型用来分析和确认业务需求，而系统模型用来规定系统开发需求，这三者之间是一种精化的关系。 5.2 业务用例模型 业务用例模型位于RUP的先启阶段，在业务建模核心工作流中完成。 5.2.1 业务用例模型主要内容 （1）业务用例视图。包括业务主角和业务用例 （2）业务用例场景。说明业务用例的执行过程 （3）业务用例规约。说明业务用例的使用者、目标、场景、相关业务规则、相关业务实体等 （4）业务规则。执行业务必需遵守的法律法规、惯例、各种规定 5.2.1 业务用例模型主要内容 （5）业务对象模型。描述关键的业务对象 （6）业务用例实现视图。业务用例的实现方式 （7）业务用例实现场景。更为明确的实现步骤 （8）包图 。组织业务用例，按业务模块或业务主角。 5.2.3 何时使用业务用例模型 使用业务用例模型 开发一个针对商业组织的软件 开发一个交互密集型软件 开发一个较大规模的软件 面对的问题领域有复杂的组织结构 所面对的业务有许多业务流程 客户希望借信息化过程进行业务重组或优化 你对这个行业了解不多，希望首先对业务有清楚的认识。 希望借由一个软件开发而打入一个行业应用软件市场 虽然对这个行业了如指掌，但希望做行业标准，因而想建立业务架构 客户已有许多孤立的遗留系统，希望做应用整合。 不使用业务用例模型 将开发一个非商业组织应用软件，如嵌入式系统 将开发一个计算密集型软件，如编码解码器 将开发的软件规模很小 所面对的问题领域组织结构单一 所面对的问题领域没有或仅有很简单的业务流程，如论坛系统 客户的信息系统已经非常成熟，只想做一些外围的小应用 对行业业务十分精通，想要快速和低成本项目，不打算做行业标准 虽然对业务不大了解，不打算在该行业深入下去 5.3 概念用例模型 概念用例模型位于先启阶段，有时在精化阶段进行，是业务用例建模的一个子集。 完整的概念用例模型 概念用例视图 概念用例分析 分析类视图 分析场景 获得概念用例 观察现有的业务用例场景，发现在不同业务用例场景中相似名称、多次出现、位于不同泳道中的活动 通过对客户业务的分析，得知对客户来说最为重要的一些业务实体。然后了解对这些业务实体可能进行的主要操作来获得备选的概念用例。 通过对客户业务流程的分析，得知客户最为关心的、影响整个流程成败的关键业务环节，备选概念用例 通过绘制概念用例分析来检验备选的概念用例。 5.3.3 何时使用概念用例模型 使用概念用例 所面对的业务领域规模庞大，业务用例粒度较大，不容易过渡到较小的系统用例 所面对的业务领域业务是网状交叉的，有跨业务用例的业务流程存在 某个业务场景过于复杂，步骤和分支过多 有超过7、8个的泳道存在 想在项目早期就获得系统原型 想在项目早期就开始建立软件架构 第一次开发这样的系统，对系统用例的决定有疑问。 不使用概念用例 所面对的业务领域规模较小，业务用例粒度较小，容易过渡到系统用例 所面对的业务领域较为单纯，基本上没有交叉业务 业务用例场景简单，不超过10个步骤 不打算太早建立软件架构 对该系统很熟悉。 5.4 系统用例模型 位于RUP先启阶段末期及精化阶段的早期。就是需求获取。 5.4.1 系统用例模型的主要内容 5.4.2 获得系统用例 1.如果已经建立了业务用例，就可以从业务用例中导出系统用例。 2.推导系统用例的基本方法是分析业务用例场景，尤其是活动图。系统用例可以从这些职责中抽取出来。然后考虑以下问题： （1）排除用例。 （2）合并用例。 （3）抽象用例。 （4）补充用例。 （5）系统用例的粒度应当与概念用例相当。 （6）系统用例的抽象角度应当与概念用例相当。 （7）概念用例所表述出的核心业务是最需要关心的部分。 5.5 领域模型 是采用业务对象（领域类）建立起来的一种模型 领域类有三种典型的形式： （1）业务对象，表示业务中使用到或产生的东西。 （2）系统