【笔记】UML核心元素

1、参与者

　　

    定义：在系统之外与系统交互的某人或某物。

　　特点：1、可以非人；2、与系统直接交互；3、主动发出动作并获得反馈；4、涉众（stakerholder）的代表

　　具有两个版型：

　　1、业务主角（business actor）：

　　在需求阶段中用于业务建模

　　特点：针对业务人员而非计算机用户

　　2、业务工人(business worker)

　　特点：在业务过程中，扮演某一环节不可或缺的部分，但是该业务并非其主动提出，并获得最后的反馈；

2、用例

　　

　　定义：定义了一组用例实例，其中每个实例都是系统所执行的一些列操作，这些操作生成特定主角可以观测的值；

　　一个完整的用例定义由参与者、前置条件、场景、后置条件组成；

　　其作用为捕捉功能性需求；

　　特点（特征）：

　　1、独立性

　　不需要与其它用例交互而肚子完成参与者的目的。

　　2、可观测性

　　对于参与者来说是可观测的。

　　3、必须由参与者发起。

　　4、命名动宾短语形式出现

　　即有发起者（参与者），也有受体。

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

　　说明：用例表达了参与者对系统的期望，一个明确的有效目标才是一个用例的来源。一个真实的目标应当完备地表达主角的期望。一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。

　　用例版型：

　　1、业务用例（business user case）

　　用于需求阶段的业务建模。

　　2、业务用例实现(business use case realization)

　　一个业务用例表达实现参与者期望的目标，业务用例实现表达完成这一目标的不同实现方法。

　　3、概念用例

　　用于概念建模，用于获取业务用例（或业务用例实现）中的核心业务逻辑，也是业务用例（实现）过程细化。

　　4、系统用例

　　得到的最终需求，用于系统建模。

　　5、系统用例实现。

　　不解释，你懂的。

3、边界

　　

　　用于划分系统与系统外界。实质上是对系统不同的抽象层次划分的一种方式。

4、业务实体类（class）

　　用于业务建模阶段建立领域模型。

　　定义：代表业务角色执行业务用例时所处理或使用的事物。一个业务实体经常代表某个对多个业务用例实例有价值的事务。一般而言，一个好的业务实体不包含关于其使用主体和使用方法的信息。

　　说明：业务实体一定是在分析业务流程的过程当中发现，而业务流程实际上就是业务用例场景。业务实体来自现实世界。

5、 包

　　一种容器，如同文件夹，用于将信息分类，形成逻辑单元。

6、分析类

　　包含边界类、控制类、实体类。

　　边界类：关键对象之间交互都要通过边界类，实际载体可能是接口，界面等。

　　控制类：行为控制，一般对应业务逻辑层。

　　实体类：一般位于数据持久层。

7、设计类

　　系统设计表达类。直接与代码（开发语言）相关，包含类名、属性、方法。

8、关系。

　　1、关联关系。

　　表达一种“知道关系”，可以单向也可以双向。静态

　　2、依赖关系。

　　两对象之间依赖的关系，一方变化，另外乙方跟着改变。一般不推荐双向依赖。

　　3、扩展关系与包含关系。

　　4、实现关系

　　比如业务用例与业务用例实例之间的关系。

　　5、精化关系

　　细化

　　6、聚合与组合关系

　　都强调整体与局部之间的关系。

　　聚合，弱依赖。

　　组合，强依赖。