<十五>UML核心视图动态视图之活动图

--->动态视图是描述事物动态行为的。

--->需要注意的是：动态视图不能够独立存在，它必需特指一个静态视图活uml元素，说明在静态视图规定的事物结构下它们的动态行为。

--->动态视图：活动图，状态图，时序图，协作图

 

--->uml中有两个层面的活动图，一种用于描述用例场景，叫［用例活动图］，另一种用于描述对象交互，叫［对象活动图］。

--->在面向对象的眼中是没有业务流程这种东西的，所谓流程只不过是在某个外部力量推动下对象之间相互交流的一个过程，它只是“瞬时”的。如果从活动图的观点来描述业务，实际上是不能直接看到对象是如何发挥作用的。这样在观念上很容易导致对象独立性被破坏。因为面向对象要求对象越独立，封装度越高越好，可是面向对象越纯粹，我们越难以理解这些对象将会干什么。正所谓上帝什么都能做，但其实它什么也没有做。所以我们面临一个这样的矛盾，既要保持面向对象观点中对象的独立性，又要保持现实世界中业务目标的过程化描述。活动图的引入解决了业务目标过程化描述，但也给对象分析造成了混乱。因此，在使用活动图时，要保持清醒的头脑，活动图只是我们用来描述业务目标的达成过程，并借此发现对象的工具。他不是我们的分析目标，也不是编程的依据，它只是对象的应用场景之一。我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键对象，然后经应该把活动图中的流程忘掉，而专心研究关键对象的特性。

 

 

--->起始点：标记业务流程的开始。一个活动图，活着说一个业务流程有且仅有一个起始点。

--->活动：是业务流程中一个执行单元

--->判断：判断根据某个条件进行决策，执行不同的流程分支。

--->同步：同步分为同步起始和同步汇合。同步起始表示它开始多个支流并行执行。同步汇合表示多个支流同时到达后再执行后续活动。

--->结束点：表示业务流程的终止。一个活动图活着说一个业务流程，可以有一个或多个结束点。

--->基本流：表示最主要，最频繁使用的，默认的业务流程分支。

--->支流：表示不经常使用的，由某个条件触发的，非默认的业务流程分支。

--->异常流：表示非正常的，不是业务目标期待的，容错性的，处理意外情况的业务流程分支

--->组合活动：可以用嵌套的活动来表示。不过这种方式会导致活动图太复杂而不清晰，建议不使用。

 

 

--->根据查询商品的对象交互过程绘制出对象活动图。

--->用对象活动图来描述对象交互的感觉并不是那么清晰。实际工作中没什么理由使用它，有更好的工具绘制对象几乎图。例如：状态图，时序图，协作图。

 

 

 

--->解决了活动图不能描述对象职责的遗憾。

 

 

--->获得业务用例之后，我们得到了参与者的业务目标，我们通过用例场景来说明如何达到业务目标。

--->我们经常以业务主角和业务工人作为泳道，以工作单元作为活动来编排活动图来描述用例场景。

--->这种活动图对我们获得概念用例，角色和业务对象（业务实体）有着很好的帮助。

（1）帮助发现概念用例（工作单元）。

  如果发现多个用例场景中类似的工作单元经常出现，就可以考虑将她抽象出来。在根据情况采用包含，扩展或者泛化关系将其连接到基本用例（即他们所贡献的业务用例）

（2）帮助发现角色

  通常，一个泳道（业务主角活业务工人）可以定义一个角色。但是如果多个用例场景中发现同一个或同一类工作单元（活动）位于不同泳道，即被不同的业务主角或业务工人使用，那么应该考虑为这些使用了同一活动的业务主角活业务工人抽象出更高级别的角色。

（3）帮助发现业务实体

  如上图，我们会发现所有活动都有着相同的命名规则：动词＋名词。这些名词就是很好的业务实体（对象）的来源。如：机票，登机牌。

（4）帮助建立领域模型。

  领域模型描述哪些对业务有着重要意义的业务对象，如果在同一个或多个用例场景的不同活动中发现某个名词重复出现。那么应当对这个名词给予重视。它很可能就是一个关键的业务对象。这个业务对象在不同活动中的状态以及它与活动图中其他名词之间的关系很可能就决定了业务的结构。绘制出这个结构就能获得领域模型。