一：）参与者
a）参与者——在建模过程中处于核心地位UML官方定义为：actor是在系统之外与系统交互的某人或事物。如图请注意系统是被一具边界包裹着。系统之外的定义说明在参与者和系统之间有一个明确的边界，参与者只可能存在于边界之外，边界之内的所有人和事物都不是参与者。边界有时在UML图中显式的画出，有时不画出，但是一谈到参与者，就应该想到边界的存在。
b)如何确定参与者
在实际的工作中，建模者常常会面临一个问题，谁是参与者？例如这样一个场景：小王到银行开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。
在这个场景中，谁是参与者呢？
可以通过回答两个问题来确定参与者与边界：
一：谁对系统有着明确的目标和要求并且主动发出动作？
二：系统是为谁服务的？
显然在这个场景中，第一个问题的答案是小王有着明确的目标：开户，并且主动发出了开户请求的动作;第二个问题的答案是系统动作的结果是给小王提供了开户的服务。小王当然就是参与者，而大厅经理和柜台职员都不满足条件，在小王没有主动发出动作以前，他们都不会做事情，所以他们不是参与者。同时，由于小王是参与者，相应地也就明确了系统边界，包括大厅经理和柜台职员在内的其他事物都在系统边界以内。
c)参与者可以非人
有时候会发现有些需求并没有人参与，参与者如何确定？例如这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这时其实就是一个计时器。还可能是一个计算机系统，一个计时器，一个传感器或者一个jMS消息。总之任何需求都必须至少有一个启动者即参与者。
d）发现参与者：
在查找参与者的过程中，可以询问以下问题以帮助确定参与者：
谁负责提供，使用或删除信息？
谁将使用此功能？
谁对某个特定功能感兴趣？
在组织中的什么地方使用系统？
谁负责支持和维护系统？
系统有哪些外部资源？
其他还有哪些系统将需要与该系统进行交互？
注意：参与者一定是直接并且主动地向系统发出动作并获得反馈的，我们以机票预定系统来分析 ：
情况一：机票购买者通过登录网站购买机票，那么他便是参与者；
情况二：假如机票购买者通过呼叫中心，由人工座席操作定票系统购买机票，那么人工座席才是真正的参与者，而机票购买者实际上是呼叫中心的参与者。
情况三：如果机票购买者通过呼叫中心的自动语音定机票而不是通过人工座席，那么呼叫中心就成为机票预定系统的一个参与者;
情况四：如果扩大系统边界，让呼叫中心成为机票预定系统的一个子系统，并且假设机票预购买者将可以自主选择通过人工座席还是自动语音还是登录网站预定机票，那么机票购买者是参与者，而人工座席则变成了业务工人。
e）业务主角（business actor）
业务主角是参与者的一个版型（所以业务主角必须遵守参与者的所有定义），特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。
它的特性在于，它针对的是业务人员而非计算机用户。在查找业务主角时必须抛开计算机，没有计算机系统这些业务人员也客观存在，在引入计算机系统之前他们的业务也一直跑得很顺畅。这是因为在初始需求价段，我们需要获得的是客户的业务模型，根据业务模型才能建立计算机系统模型。如果在了解业务的价段就引入计算机系统概念，将会混淆现有业务和将来有计算机参与时的业务。要记住，要建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清楚客户的业务，而不是预先假设已经有了一个计算机系统，再让客户来假想需要计算机系统帮他们做什么。
所以在初始需求价段，请务必使用业务主角，时时牢记业务主角是
客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色。业务主角必须在实际业务里能找到对应的岗位或人员。
f)业务工人（business worker）：建模者经常会被 一个问题困扰，有些人员参与了业务，但是身份很尴尬，他是被动参与业务的，不好说他有什么具体的目的，但是他又的确在业务过程中做了事情，到底要不要为这样的人建模？这种情况就是订票系统中的人工座席。人工座席可以定票，可是他本身是系统边界的一部分，而且没有购票人拨打电话，他是不会去定票的。看上去他只是购票人的一个响应器，或者他是为购票人购票过程中服务的一环。
那么如何判断一个人是参与者还是业务工人呢？
他是主动向系统发出动作的吗？
他有完整的业务目标吗？
系统是为他服务的吗？
这三个问题的答案如果是否定的，那他一定是业务工人。
g)参与者与涉众（stakeholder）的关系
涉众是与要建设的这个系统有推己利益相关的一切人和事，涉众的利益要求会影响系统的建设。他虽然与这个系统有利益相关，但并非所有的涉众都是系统的参与者。假设一个系统的建设是由一家国际风险投资机构投资的，这个系统必然与这家投资机构有着利益关系，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许会构成一些约束。但投资方并不会参与 系统的建设，它只是从资本上拥有这个系统并从将来的收入中获得回报。
参与者是涉众代表。参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。
h）参与者与用户的关系
用户（user）是指系统的使用者，通俗一点说就是系统的操作员。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。例如在建设办公自动化系统的过程中常常会有这样的情况，局长是一个参与者，他向系统提出了如何审批的要求。但是局长这个参与者最终可能并不是系统用户，他将所有的操作都交给秘书，这时秘书作为局长代理来使用系统。另一种情况是，局长还分为正局长还副局长，但是实际上只有副局长最终使用系统，这时副局长就作为局长这一参与者的实例来使用系统。
i）参与者与角色的关系
角色（role）是参与者的职责。角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。一个角色代表了系统中的一类职责。例如办公自动化系统中，正副处长，正副局长都可以审批文件，审批文件这一职责就可以用一个角色来代表，比如命名一个文件审批者角色来代表审批文件这一职责。现实中可能并无文件审批者这样一个具体的参与者，但是参与者的相同职责通过角色来定义，将为系统带来好的灵活性。
j)总结：参与者是涉众的代表，它代表涉众对系统的利益要求，并向系统提出建设要求;参与者通过代理给其他用户或者将自身实例化成用户来使用系统；参与者的职责可以用角色来归纳，用户被指定扮演哪个或哪些角色因此来获得参与者的职责。
二：)用例
定义：由参与者驱动的，并且给参与者提供可观测的有意义的结果的一系列活动的集合，而用例的来源就是参与者对系统的期望。
用例在UML建模中是最最重要的一个元素。之所以说它重要， 是因为UML是面向对象的，除用例之外，所有其他元素都是“封装”的，“独立”的。而对于对象来说他们又都是在没有“外力”的作用时是“鸡犬之声相闻，老死不相往来”的，而用例正是施加这一“外力”的元素，正是用例使得其他那些“孤独”的UML元素能够共同组成一篇有意义文字。因而没有准确的用例定义一切都无从谈起。
用例是一种把现实世界的需求捕获下来的方法。这个世界的功能性体现在，首先有某人的一个愿望，这个愿望驱使会做事并获得一个确定的结果。如果 没有愿望，功能性也就无从谈起。一个系统就是由各种各样的愿望 组成的，换句话说，各种各样的为为着各自的目的做着各种各样的事情共同组成了一个系统。
官方文档对用例是这样说的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这虚张声势只剩生成特定主角可以观测的值。
一个用例就是与参与者交互的，并且给参与者白日做梦中观测的有意义的结果的一系列活动的集合。穿上说法应当更清楚一些。所谓的用例就是一件事情，要完成这件事件，需要做一系列的活动；而做一件事情可以有很多不同的办法和步骤，也可能会遇到各种意外的情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景。
综上所述 ：一个完整的用例定义由参与者，前置条件，场景，后置条件构成。如要做饭，首先得要有饭，这是启动用例的前提，也称为前置条件;用例执行完了，会有一个结果，米变成了饭。这称为后置条件。
用例的一些特性：
a)用例是相对独立的。这意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例从“功能”上说是完备的。用例本质体现了系统参与者的愿望，不能完整达到参与者愿望的不能称为用例。例如取钱是一个有效的用例，而填写取款单却不是。因为完整的目的是取到钱，没有人会为了填写取款单而专门跑一次银行的。
b)用例的执行结果对参与者来说是可观测的和有意义的。
例如，一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前执行备份操作。虽然它是系统的一个必需组成部分，但它在需求价段却不应该作为用例出现。因为这是一个后台进程，对与参与者来说是不可观测的。再比如说：登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯地输入密码却是没有意义的。输入完了呢？有什么结果吗？如图
c)这件事必须有一个参与者发起。不存在没有参与者的用例，用例也不会自动启动，也不 应该主支启动另一个用例。如ATM取钱是一个有效的用例，而ATM吐钞却不是。因ATM无缘无故是不会吐钞的。
d)用例必然是以动宾短语形式出现的。
用例必须有一个动作和动作的受体。如喝水是一个有效的用例，而喝和水却不是。
e)发现用例
因为用例的来源就是参与者对系统的期望。所有发现用例的前提条件是发现参与者；而确定参与者的同时就是确定了系统边界。在开始获得用例之前，我们需要做好前期的准备工作:
在这里我们将参与者这个叫法改为“主角”，用于特别强调并区分业务工人（business worker）的区别。
主角是位于系统边界外的。
主角对系统有着明确的期望和明确的回报要求。
主角的期望和回报要求在系统边界之内。
接下来就是对主角即业务代表进行访谈。访谈时不要试图让业务代表为你描述整个业务流程，也不要涉及表单填写一类的业务细节，甚至你可以不关心业务规则，更不要试图让业务代表现解将来的计算机系统会如何工人。你只要让业务代表从他自己的本职工作出发来谈谈他的期望。可以问下面问题：
您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事情的目的是什么？您做完这件事希望有一个什么样的结果？
d)业务用例：业务用途（business use case）是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时应当使用这种版型。业务用例专门用于业务建模它与计算机系统建模无关，它只是业务领域的一个模型，通过业务模型可以得到业务范围，必须说明的是业务范围不等于需求，软件需求的真正来源是系统范围，而业务模型是系统模型的重要输入。业务用例是用于描述客户现有业务的，所以它所面对的问题领域是没有将来的计算机系统参与的目前客观存在的业务领域。例如：
为一个图书馆开发借书系统，建立的业务模型基于客户的现有业务的，也就是说哪怕我们明明知道计算机可以实现自动提示哪些读者逾期没有归还图书这一要求，在业务建模时业务用例也不应该将计算机包括进来。之所以不把计算机引入进来，是因为业务范围不等于系统范围，不是所有的业务都能够用计算机来实现的，不能用计算机实现的业务就不可进入系统范围，如假设图书馆有一项检查借阅人 身份证件是否真实的业务，然而众所周知，第一代身份证是不可以通过计算机来检查的。
e)业务用例实现（business use case realization）也是用例的版型的一种，它也就是业务用例的一种实现方式。一个用例可以有多种实现方式，它们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类。比如：交电话费我们中以到营业厅交也可以网上在线交还可以预存话费。
f)系统用例：也就是我们常常说的用例，它是用来定义系统范围，获取功能性需求的。
因此它是软件系统开发的全部范围，系统用例是我们得到的最终需求。业务用例是客户业务的视角，而系统用例采用的是系统的视角。
g)用例实现：准确应该叫：系统用例实现类似业务用例实现一个用途实现代表了一种实现方式。如我们要在网上申报业务，就要提交申请。考虑到填写内容较多，时间过长，会话可能失效，也考虑到有些用户使用拨号上网带宽窄速度慢的问题，系统打算支持两种提交方式，在线提交申请，另一个是离线提交申请。