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、聚合与组合关系
都强调整体与局部之间的关系。
聚合，弱依赖。
组合，强依赖。
原文：http://www.cnblogs.com/Jnw-qianxi/p/3707972.html