一、stereotype（类型、构造型）
这个概念是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。
二、参与者
参与者：在系统之外与系统交互的某人或某事物。由定义可知参与者包含以下两个特点：
1）参与者位于边界之外；
系统之外的定义说明在参与者和系统之间有一个明确的边界，参与者只可能在边界之外。要弄明白谁是参与者首先要闹明白系统的边界。可通过以下问题来确定系统的边界：谁对系统有着明确的目标和要求并且主动发出动作？系统是为谁服务的？
2）参与者可以非人。
例如每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？功能性需求的用例有个特征是“不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例”。任何一个需求都有启动者，如果找不到启动者，那么它就不是一个功能性需求。例如：客户提出要建立的系统界面很友好，在每个页面上都有操作提示。这个要求就找不到启动者，他就不是一个功能性需求，实际上他是系统可用性的一个具体要求。回到开头的问题，这个需求的参与者就是一个计时器，它每天在某个固定的时刻启动这个需求。
业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。其特殊性在于，它针对的是业务人员而不是计算机用户。
业务工人：被动参与业务，不需要建立业务模型，常见于领域模型和用例场景。最直接区分参与者和业务工人的方法是判断在边界之外还是边界之内。以下三个问题可用来区分业务工人：1）他是主动向系统发出动作的吗？2）他有完整的业务目标吗？3）系统是为他服务的吗？
三、用例
作用：用例用于捕捉功能性需求。
定义：一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。
特征：1）用例是相对独立的。即它不需要与其他用例交互而独自完成参与者的目的。用例本质提现了参与者的愿望，不能完整达到参与者愿望的不能称为用例。例如取钱是一个有效的用例，填写取款单却不是。
2）用例的执行结果对参与者来说是可观测的和有意义的。比如有个后台进程监控参与者在系统里的操作。虽然他是系统的一个必须的组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对参与者来说是不可观测的，他应作为系统需求在补充规约中定义而不是一个用户需求。
3）用例必须由参与者发起，不存在没有参与者的用例。用例不该自动启动，也不该主动启动另一个用例。
4）用例必然是以动宾短语形式出现。
5）一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、甚至部署单元。
粒度：项目阶段不同，使用不同的粒度。
在业务建模阶段，用例的粒度以每个用例能说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。
在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。此阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。
在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能描述操作者与计算机的一次完整交互为宜。
不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级。
