UML学习笔记（一）

  抽象角度:参与者的目标就是你的抽象角度。

  建模公式：

a)     问题领域=所有抽象角度求和

b)     抽象角度=问题领域边界之外的参与者的业务目标=业务用例

c)     业务用例= 所有特定场景求和

d)     特定场景=静态的事物+特定的条件+特定的动作    或者

       特定的事=特定的事物+特定的规则+特定的人的行为

  抽象层次：抽象层次越高，具体信息就越少，概括能力越强；反之，具体信息就越多，概括能力越弱。找准抽象层次很重要。

  视图：

a)     视图用于组织UML元素，表达出模型的某一方面的含义。

b)     视角是人们观察事物的角度。

c)     建模最最主要的工作就是为软件绘制那些表达软件含义的视图来完整地表达软件的含义。

d)     建模的另一项重要工作就是为不同的干系人展示他们所关心的那部分视角。

  对象分析方法：

a)    一切都是对象一切有名字的东西都是对象。

b)    对象都是独立的对象是离散的，他不是因为有个场景二存在的。场景中的对象只是对象“映射”到场景的一个侧面（对象实例）。归纳整理对象的多个实例抽象出对象的一般特性。<不论是用例、类、包、组件等都是独立于那个场景的，不要将对象局限在那个场景中！>

c)     对象都是具有原子性在同一抽象层次上，在分析过程中都应当把对象市委一个不可分割的原子。对象总有一个边界，永远也不应该打破边界去窥探对象的内部

d)    对象都是可抽象的 应当关注那些参与了很多场景的对象，它们往往是分析设计中的重点以及成败的关键。

e)    对象都有层次性对象是有着抽象层次的。

   参与者（主角） 参与者在建模过程中是出于核心地位的。参与者位于系统边界之外。一谈到参与者，就该想到系统边界的存在，否者参与者就是可疑的。

   找出参与者从而确定系统边界（通过下面两个问题）

a)     谁对系统有着明确的目标和要求并且主动发出动作？

b)     系统是为谁服务的？

  业务主角 建立业务模型、查找业务用例都必须使用业务主角，而不是普通参与者。（业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色）

   业务工人 判断（任意问题存在否定就是业务工人）：

a)     他是主动向系统发出动作的吗？

b)     它有完整的业务目标吗？

c)     系统是为它服务的吗？

  用例

a)      定义：用例定义了一组用例实例，其中每个实例都是系统实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。（一个完整的用例定义由参与者、前置条件、场景、后置条件构成）

b)      特性：

                i.         用例是相对独立的

               ii.         用力的执行结果对参与者来说是可观测的和有意义的

              iii.         这件事必须由一个参与者发起

              iv.         用例必然是以动宾短语形式出现

               v.         一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、甚至是部署单元

   *用例颗粒度一个系统的业务用例一般在[10，50]之间，必须把握的原则是在同一个需求阶段，所有的用例颗粒度应该是同一量级的。