UML分析

业务用例是客户业务视角，系统用例是系统视角

概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业
务用例之间的关系。一般来说这些关系有扩展、包含和精化。

“分解”较大的业务用例所产生的结果就是概念用例。请注意分解两字的引号，实际上用例不是功能，是不可分解的，同时由于用例具有“原子”性，用例也是不能分解的。正确的说法是抽象。抽象出的概念用例通过包含、泛化、扩展关系连接到基本业务用例。

关联关系：在最终的代码里，关联对象通常是以实例变量（成员变量）的形式实现的。

在用例模型中，单向关联关系用于连接参与者和用例，箭头由参与者指向用例，表示
参与者“知道”用例的存在。当然，在有些UML建模工具中，方向是不被强调的，不过我们从用
例知识中了解到，总是参与者“知道”用例，而用例是“不知道”参与者的。

一般而言，依赖关系在最终的代码里体现为类构造方法、类方法等的传入参数。与关联关系相比，依赖关系除了临时“知道”对方外，还会“使用”对方的属性或方法。从这个角度讲，被依赖的对象改变会导致依赖对象的修改。

业务用例实现视图展现业务用例有哪些实现途径。
绘制业务用例实现视图都是一个好习惯，是符合软件工程需求可追溯原则的好的做法。

扩展关系中基本用例的基本流执行时，扩展用例不一定执行，即扩展用例只有在基本用例满足某种条件的时候才会执行。

包含关系中基本用例的基本流执行时，包含用例一定会执行。

当多个用例共同拥有一种类似的结构和行为时，可以将他们的共性抽象成为父用例，其他的用例作为泛化关系的子用例。

领域模型是从所有业务用例场景对象交互模型当中抽象出来的更高级别的业务对象模型；它表示了业务对象结构和交互的一般规律，揭示了业务运行的“本质”和“核心”。

如果您构建应用程序时的主要目的是管理和提供信息（例如，订单管理系统或银行系统），
那么您可能选择在业务级别上构建该信息的模型，而不考虑该业务的工作流程。这就称为领域建
模。通常，领域建模是软件工程项目的一部分，它是在项目的先启阶段和精化阶段中执行的。

了解业务，目标

目标相关的人和物，发现和定义涉众，涉众不等于用户

涉众概要 涉众简档   用户概要 用户简档

与业务建模不同的是，我们的视角和建模目的已经从原来的描述业务、理解业务变成了理解系
统、描述系统。这两者的差别在于引入了计算机。之前的描述是原来的业务是什么样子工作人员
怎样完成业务，而现在的描述应该变成计算机怎样做，工作人员怎样操作计算机。

业务用例是以整个永久用电申请业务为粒度的；概念用例是以核心业务当中的关键步骤为粒度的；而系统用例基本上就是以一次完整的人机交互过程为粒度了。

建立分析模型。

在面向对象里，聚合与组合关系非常相似，聚合在语义上表现为整体由部分构成，当整体消亡时，部分仍然存在，组合在语义上表现为整体拥有部分，当整体消亡时，部分也一起消亡。

依赖关系是一种动态关系，并且表现为行为上的依赖而不是属性的依赖。