大象Thinking.in.UML第二版读书笔记第5章：UML核心模型

5.1用例模型概述

用例模型很重要，用例模型是需求工作流程的结果。

用例的三个层次解释并对相应三个模型
业务用例----------业务用例模型
概念用例----------概念用例模型
系统用例----------系统用例模型

• 业务用例模型—>用于识别和规定业务需求
• 概念用例模型—>用于分析和确认业务需求
• 系统用例模型—>用于规定系统开发需求

5.2业务用例模型

业务用例模型并不仅仅是很多人理解的有主角和业务用例绘制的视图，视图只是一个提纲和高层展示。下图是完整的业务用例模型锁具有的必要视图和工件，他们共同完成业务建模的工作。

5.2.1业务用例模型主要内容

• 业务用例视图
• 业务用例场景
• 业务用例规约
• 业务规则
• 业务对象模型
• 业务用例实现视图
• 业务用例实现场景
• 包图

5.2.1业务用例模型工件的取舍

5.2.1何时使用业务用例模型

略

5.3概念用例模型

是一种从业务用例中“抽取”出针对某个关键业务流程产生贡献的工作单元，再用这些工作单元来组织成这个业务流程，以得到对业务流程的理解。这个抽取过程也是概念用例的建立过程。

5.3.1概念用例模型主要内容

• 概念用例视图
• 概念用例分析
• 分析类视图
• 分析场景

5.3.2获得概念用例

略……没什么太重要的

5.3.4何时使用概念用例模型

概念模型是业务用例模型和系统用例模型中间的过度模型。
时机：略

5.4系统用例模型

官方文档定义为系统既定功能及系统环境的模型，可以作为客户和开发人员的七月。是贯穿整个系统开发的一条主线。

从作用上将完全等同于“需求规格说明书”，它将作为合同附件来约定系统的开发范围。

也是客户理解系统的重要途径

5.4.1系统用例模型主要内容

• 业务用例
• 概念用例
• 用例视图
• 用例规约
• 补充规约
• 业务规则
• 用例实现
• 用例场景
• 分析对象

5.4.2获得系统用例

• 排除用例
• 合并用例
• 抽象用例
• 补充用例
• 系统用例的粒度应当与概念用例相当
• 系统用例的抽象角度与概念用例相同
• 概念用例锁表述出来的核心业务是最需要关系的部分

5.5领域模型

领域类有三种典型的形式：
业务对象，表示业务中使用到或产生的东西。如订单，账号，合同等
系统需要处理的现实世界中的对象和概念。如商品，卖家，买家等
将要发生或已经发生的时间，如购买，撤单，付费等

领域模型不关注使用者的信息和好用过程，只帮助我们理解问题领域中的关键概念和关键对象。帮助我们理解这些对象如何工作，以及如何解决问题。

一般先建立业务模型，再来推到领域模型

5.6分析模型

分析类用于获取系统中主要的职责簇。他们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”

ps：很重要
商业系统无论多复杂，无论什么行业，其本质无非是人、事、物、规则。人是一切的中心，人做事，做事产生物，规则限制人事物，人驱动系统，事体现过程，物记录结果，规则则是控制。无论面向对象也好,UML也罢，复杂的表面下其实只是一个简单的法则，系统分析员弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，商业建模也就基本完成了。

5.6.1如何使用分析模型

应当注意的几个原则

• 边界类不应当与实体类之间有依赖关系，边界类只能通过控制类与实体类交互。
• 实体类和实体类之间可以有聚合或组合关系，但不应当有依赖关系。不应当直接交互，而只能通过控制类间接交互
• 控制类和控制类之间不应当有聚合或组合关系，应当尽量减少依赖关系
• 正确的依赖关系应当是边界类依赖控制类，控制类依赖实体类。而不能反过来
  
  
  调整分析类主要来自如下几个方面
• 业务规则
• 结果优化
• 分离职责

5.6.2分析模型主要内容

5.6.3分析模型的意义

分析模型采用mvc模式，用例场景中描述的业务分解为边界（操作见面和展示界面）、控制（业务逻辑）、实体（业务数据），用着三个语速建立实现用例场景的对象模型。
略

5.7软件架构和框架

架构代表了一个软件项目对系统的定义和理解，软件架构在较高的抽象层次上，将系统规划为一些独立的逻辑不见，各负其责，这些不见通过标准的通信接口传递信息。一个架构就是一个系统的骨架。

架构是系统蓝图，是对系统的高层次的定义和描述。框架是解决方案，是加速和提高系统质量的半成品。

5.7.1软件架构

5.7.1.1业务架构
业务架构的目标是为业务领域建立一个维护和扩展的逻辑结构，描述业务的构成。业务架构也是软件架构的重要输入。

业务架构来源于两个主要的输入：业务用例和领域模型。

业务架构可以使用领域包和组织结构包来表示业务主要领域和组织结构关系。

从某个角度看，业务架构图很像商业模式。

5.7.1.2软件架构
软件架构需要在业务架构的基础上引入计算机环境。软件架构需要说明业务架构如何分布在计算机环境中，并得以执行

一个典型的软件架构包括两个视角，广度视角和深度视角，这两个视角构成对软件架构的立体秒速。

广度视角及常见的软件层次结构，关注软件的分层，规定每一层的职责及层之间的通讯标准。一般使用层包元素来绘制。

深度视角是指官渡视角中每一层的详细说明，关注每一层，以及每个部分的具体实现架构

5.7.1.3架构描述
架构描述通过架构文档记录，可以把业务架构文档和软件架构文档分开或合并描述
主要包含以下内容

• 业务架构概述
• 组织结构
• 业务模块
• 业务对象模型
• 典型用例场景
• 软件架构概要
• 计算环境
• 软件层次
• 实现架构
• 协议和结构
• 软件框架
• 典型用例场景的架构实现
• 非功能性需求

5.7.2软件框架

软件框架是针对一个普遍问题的最佳实践或解决方案，它通常都是一个半成品，提供基本类库，变成模型和变成规范。

5.7.3何时使用架构和框架

架构可选，框架必须

即使软件规模在校，也不要上来就编码，先花费一些时间建立或选择一个框架，甚至一开始只包括简单的几个接口和规范，也比没有框架腰好。实际上除了统一过程这种重量级方法鼓励使用框架（自研框架）外，许多轻量级的方法如极限编程与敏捷开发等，也都鼓励通过不断的重构来形成框架，提高软件质量。

5.8设计模型

设计模型就是我们所熟知的详细设计。设计模型采用设计类绘制，需要考虑实现语言、架构、框架、编程模型、规范、目标是用程序逻辑来实现用例。

设计模型是编码实现之前的最后第一道建模工序。

5.8.1设计模型的应用场合

略

5.8.2设计模型的主要内容

要考虑到使用的编程语言的语言特性

5.8.3从分析模型映射到设计模型

5.9组件模型

组件与架构密不可分。
定义组件是为了：

• 这些组件将成为可以复用的单位
• 这个组件都有一组特定的功能
• 这些组件将成为可以独立部署的单位
• 这些组件将遵循架构规范

5.9.1何时使用组件模型

略

5.9.2广义组件的用法

组件可以视为一个包，也就是广义上的组件

• 描述个逻辑模块间的关系，使用组件模型------模块，如登录模块
• 描述应用系统中各个子系统之间的关系，使用组件模型-----子系统，如话题子系统
• 打算描述应该程序中使用到的各个公共或基础类库—类库
• 描述系统中各个可执行部分之间的关系------可执行程序
• 描述应用系统中各个程序包之间的关系------包

5.10实施模型

实施模型有卑职节点和组件组成。
配置节点使用节点元素绘制，描述系统硬件的物理拓扑结构
组件使用组件元素绘制，表示在配置图中描述的结构上执行的软件