UML核心模型

业务用例模型

该模型要注意区分的是，业务用例模型，不属于需求流，我们习惯上常见的需求指的是系统需求，属于计算机范围的，软件系统要实现的功能范围，这种系统需求是由系统用例模型来说明的。这种需求只是整个需求过程的一部分，仅仅说明要在计算机中实现的那一部分。

而业务用例模型，是对现实业务在没有计算机设计等其他因素干扰下的直观理解，容易达成客户与开发方的理解。另外，业务用例可以准确完备的表达客户的现存或预想的业务。而系统用例模型则可能只是片段或者部分。也就是说，业务用例模型讲述的是业务范围，而系统用例模型讲述的是系统范围。

同时业务用例模型，也不仅仅是很多人理解的由主角和业务用例绘制成的视图，视图只是一个提纲和高层展示。如下展示一个完整的业务用例模型。

但业务用例模型，需要根据实际项目来定，是否需要绘制。

概念用例模型

概念用例模型，是业务用例建模的一个子集。在UP过程中，官方并未强调概念用例的建立，也没有专门的工作流来完成它们，但项目复杂时，由于业务用例的粒度较大，而系统用例的粒度又较小，因此，概念用例在过渡这种大粒度到小粒度时，非常有用。

针对大粒度用例，我们通过抽象出关键和核心的工作单元，针对这些单元建立模型来简化业务，即得到概念用例。

同时，我们也可以根据抽取出对某个关键业务流程产生贡献的工作单元，再用这些工作单元来组织成这个业务流程，以得到对业务流程的理解。下图展示完整的概念用例：

系统用例模型

即常说的需求获取。

领域模型

领域模型用来针对问题领域中某个我们关心的问题来建立对象模型，它代表系统工作环境中存在的事情或者发生的事件。一般有三种典型的形式:

1.业务对象，表示业务中使用到或者产生的东西。

2.系统需要处理的现实世界中的对象和概念。

3.将要发生或者已经发生的事件。

领域模型是一种不完整的业务对象模型，因为它并不包括使用者的信息和使用过程，它可以帮助我们理解问题领域中的关键概念和关键对象，帮助我们理解这些对象如何工作，以及如何解决问题。建议从业务模型来推导领域模型。

通常在非交互密集型的软件建立领域模型，因为他们参与者很少，如手机软件，工控程序，PC游戏等。其实UML并非一定要用用例，只有在交互密集型软件中，用例才能发挥其作用，而在非交互密集型软件中，用例的意义不大，这时最合适的是为问题领域建立领域模型。

还有一种情况下，就是交互密集型软件的交叉和重叠的对象建立领域模型，例如生产线，对产品的整个生命周期做领域模型。

以上，总之，领域模型不针对参与者来建立，而是描述关键业务对象的行为和交互模式。

分析模型

在RUP中，分析模型是可选的，是从需求到设计模型转换的过渡，如何获得分析类：

采用时序图，在用例场景中的参与者与系统之间加入一个边界类代表操作界面，在边界类与实体类交互之间加入一个控制类代表业务逻辑，然后对照用例场景，一步一步忠实地把用例场景过程分析类实现出来。

软件架构和框架模型

架构和框架，是完全不同的两种东西，框架是针对某个问题领域的通用解决方案，它通常集成了最佳实践和可复用的基础架构，对开发工作起到减少工作量，指导和规范的作用。

可以说，架构是战略性的，它描述部署，职责，战略目标，指挥系统，信息传递等，框架则是战术性的，它描述组织，建设，作战方案，命令下达，战术执行。

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

对软件来说，架构需要描述两个方面的内容：

1.业务架构

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

业务架构来源于业务用例和领域模型。业务架构可以使用领域包和组织结构包来表示业务主要领域和组织结构关系，同时，业务架构需要一份文档：

描述每个领域包的职责，与其他领域包的关系

在文章中引用用例模型来阐述典型业务是 如何在这个业务架构中运行的。

对一些重要的领域，使用领域模型来解释它如何运行。

用例模型，领域模型所描述的业务流程，通过抽象可得到业务架构。

2.软件架构

软件架构需要在业务架构的基础上引入计算机环境，包含软，硬件环境。一个典型的软件架构，包含两个视角，广度视角和深度视角。

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

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

设计模型

设计模型，其实就是我们常说的详细设计，用作实施和测试活动的基本输入，描述用例实现的对象模型，它可作为对实施模型及其源代码的抽象。

设计模型在以下几个场合非常有用：

1.软件架构场合

用设计模型来解释软件架构如何运行，以及描述如何使用架构的编程模型。

2.软甲框架场合

解释框架如何运行，如何使用框架的类库以及开发时应当怎样遵循编程模型。

3.典型场景场合

它成为开发人员的指导和规范，针对典型需求场景。

统一过程提供了一组规则和指导原则来帮助从分析类到设计类的映射实现，他们是：分析类代表设计元素的实例所承担的角色，这些角色可以由一个或多个设计模型元素来实现。此外，单个设计元素可以实现多个角色。

组件模型

从上面可以看到，组件总是用来容纳分析类和设计类的，可以把组件理解为一个包。只不过普通的包只起到组织和容纳，而组件的组织行为却有着特别的目的：这些分析类或者设计类被组织起来完成一组特定的功能。

组件总是与架构在一起的，组件必须符合某个架构的规范要求。在考虑是否要建立组件模型前，应当先决定软甲架构。对于组件来说，架构是组件的设计规范，是组件的安装平台，是组件的运行环境，是组件的管理环境，生成组件的目的是复用，因此，部署组件的架构要能够兼容生成组件的架构。

另外组件和部署也息息相关，架构决定了组件的运行环境，组件将被部署到架构所决定的环境中去。

一开始组件并没有实现代码，它只有预定义的功能和对外暴露的接口。定义组件是这样的目的：

1.这些组件将成为可复用的单位。

2.每个组件都有一组特定的功能。

3.这些组件将成为可独立部署的单位。

4.这些组件将遵循架构规范。

要注意的是，组件很可能不是系统必须的，即使没有组件，能够实现组件功能的那些类依然存在，只是需要做更多的工作。

广义上的组件，是抛弃了组件特性的组件，只是将组件视为对物理代码进行组织的一个包，此时的组件已经不在具备完整组件的含义，它只代表可执行代码的一种分组方式，这是，称为构件。此时，组件可有以下场合：

1.模块

2.子系统

3.类库

4.可执行程序

5.包

总之，组件是代码的一种逻辑分组。在一些场合下描述系统结构还是很有意义的。

实施模型

由配置节点和组件来组成。通常用在分布式系统中，通常节点表示一个计算单元，即硬件，组件则代表可执行的物理代码模块。

这里对UML做个初期总结：

实际上，通过这几天对核心元素，核心视图，核心模型的学习，UML告诉你的，实际上关键是在你清楚的知道你要做什么，你的软件决定你的模型，你的模型决定你的视图，而你的视图又决定你的元素。