用例图：用例模型是用例图描述的，用例模型可以由若干个用例图组成，用例图中包含系统，角色和用例等三种模型元素，图示用例图时，既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化，关联，依赖）
用例内容被看作用例元素的文档性质。
系统：是用例模型的一个组成部分，代表的是一部机器或一个商务活动，而并不是真正实现的软件系统，系统的边界(功能)用来说明构建的用例模型的应用范围。准确定义系统的边界不是件容易的事，一般的作法是，先识别出系统的基本功能，然后以此为基础定义一个稳定的，精确定义的系统架构，以后再不断地扩充系统功能，逐步完善。
在建模初期，定义一些术语和定义是很有必要的，因为在描述系统，用例，或进行作用域分析时，采用统一的术语和定义能够规范表述系统含义，不致出现误解。
角色：是与系统交互的人或事。所谓“与系统交互”指的是角色向系统发送消息，从系统中接收消息，或是在系统中交换消息。，只要使用用例，与系统互相交流的任何人或事都是角色。角色是一个群体概念，代表的是一类能使用某个功能的人或事，角色不是指某个个体。
角色是启动用例的前提条件，又称为刺激物，角色先发送消息给用例，初始化用例后，用例开始执行，在执行过程中，该用例也可能向一个或多个角色发送消息。
主要角色：指的是执行系统主要功能的角色；次要角色：指的是使用系统的次要功能的角色，次要功能是指一般完成维护系统的功能
如何发现角色？
思考：
使用系统主要功能的人是谁？
需要借助于系统完成日常工作的人是谁？
谁来维护，管理系统（次要角色），保证系统正常工作？
系统控制的硬件设备有哪些？
系统需要与哪些其它系统交互？其它系统包括计算机系统，也包括该系统将要使用的计算机中的其他应用软件，其它系统也分为二类，一类是启动该系统的系统，另一类是该系统要使用的系统
对系统产生的结果感兴趣的人或事是哪些？
在寻找系统用户的时候，不要把目光只停留在使用计算机的人员身上，直接或间接地与系统交互或从系统中获取信息的任何人和任何事都是用户。
uml中的角色是具有版类《角色》的类，该类的名字用角色的名字命名，用以反映角色的行为。角色类包含有属性，行为和描述角色的文档性质
由于角色是类，所以它拥有与类相同的关系描述。在用例图中，只用通用化关系描述若干个角色之间的行为
用例代表的是一个完整的功能，uml中的用例是动作步骤的结合。动作是系统的一次执行，与角色通信或进行计算，或在系统内工作都可以称作动作，用例应支持多种可能发生的动作。
用例的特征：
1，用例总由角色初始化
用例所代表的功能必须由角色激活
2，用例为角色提供值
用例必须为角色提供实在的值，虽然这个值并不总是重要的，但是能被角色识别。
3，用例具有安全性
用例是一个完整的描述。
用例和角色之间也有链接关系，用例和角色之间的关系属于关联，又称作通信关联，这种关联表明哪种角色能与该用例通信，关联关系是双向的一对一关系，即角色可以与用例通信，用例也可以与角色通信。
用例的命名方式与角色相似，通常用用例实际执行功能的名字命名。用例表示的也是一个类，而不是某个具体的实例，用例描述了它代表的功能的各个方面，也就是包含了用例执行期间可能发生的种种情况。
如何发现用例：
思考：
角色需要从系统中获得哪种功能？角色需要做什么？
角色需要读取，产生，删除，修改或存储系统中的某种信息吗？
系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件能干些什么？
如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？
还有一些与当前角色可能无关的问题，也能帮助建模者发现用例
例如：
系统需要的输入/输出是什么信息？这些输入/输出信息从哪来到哪去？
系统当前的这种实现方法要解决的问题是什么？
uml中的用例用椭圆形表示，用例的名字在椭圆的内部或下方，用例位于系统边界的内部，角色与用例之间的关联关系用一条直线表示。
用例之间的关系
用例之间有扩展，使用，组合三种关系，扩展和使用是继承关系的另一种体现形式，组合则是把相关的用例打成包，当做一个整体看待。
1，扩展关系
一个用例中加入一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称扩展关系，用例的具体功能通常采用普通的文章描述。
2,使用关系
一个用例使用另一个用例时，这两个用例之间就构成了使用关系，一般情况下，如果若干个用例的某些行为都是相同的，则可以把这些相同的行为提取出来单独作为一个用例，这个用例称为抽象用例，这样，当某个用例使用该抽象用例时，就好像这个用例包含了抽象用例的所有行为。
图形化表示的用例本身不能提供该用例所有的全部信息，因此还必需描述用例不可能反映在图形上的信息，通常用文字描述用例的这些信息，用例的描述其实是一个关于角色与系统如何交互的规格说明，该规格说明要清晰明了，没有二义性。描述用例时，应着重描述系统从外界看来会有什么样的行为，而不管该行为在系统内部是如何具体实现的，即只管外部能力，不管内部细节。
用例的描述应包括下面几个方面：
1，用例是怎样被角色启动的
2，用例的目标
3，角色与用例之间的消息流
4，用例的多种执行方案
5，用例怎样才算完成并把值传给角色
描述用例仅仅是为了站在外部用户的角度识别系统能完成什么样的工作，至于系统内部是如何实现该用例的，则不用考虑，描述用例的文字一定要清楚，前后一致，避免使用复杂的易引起误解的句子，方便用户理解用例和验证用例。
对于已经包含完全性和通用性描述的用例来说，还可以在补充描述一些实际的脚步，用脚本说明用例被实例化后系统的实际工作状况，帮助用户理解复杂的用力。注意，脚本描述只是一个补充物，不能替代用例描述。
对某个用例的描述完成之后，可以用一个具体的活动跟踪一下，检查用例中描述系统能否被识别，在执行这个活动时，可以通过回答下列问题找出不足之处。
用例中的所有教师与该用例都有关联关系吗？
若干个角色的通用行为与基类角色的行为是否相似？
表示同一个活动流的多个用例之间是否存在相似性，他们是否能使用关系描述为一个用例
用例扩展关系中描述的特殊情况存在吗？
有没有存在无任何通信关联的角色或用例？如果有，那么用例一定存在问题，否则为什么还要这个角色
有没有遗漏与需求的功能相对于的用例？如果有，那么就要新建一个用例。
不要把所有的用例建好之后，再去识别用例的关系是否正确，这种做法有时会导致错误。
用例可用于测试系统的正确性和有效性，正确性表明系统的实现符合规格说明，有效性保证开发的系统是用户真正需要的系统。
有效性检查一般在系统开发之前进行，当用例模型构造完成后，开发者将模型交给用户讨论，由用户检查模型能否满足他们对系统的需求。
正确性测试保证系统的工作符合规格说明，常用的测试方法，一种是用具体的用例测试系统的行为ie，又称“漫游用例”；另一种是用用例描述本身测试，或称定义测试。
uml中实现用例的基本思想是用协作表示用例，而协作又被细化为若干个图，协作的实现用脚本描述：
（1）用例实现为协作
协作是实现用例内部依赖关系的解决方案，通过使用类，对象，类之间的关系和他们之间的交互实现需要的功能，协作的图示符号为椭圆，椭圆内部或下方标示协作的名字。
（2）协作用若干个图标示
标示协作的图有协作图，序列图和活动图，这些图用于标示协作中的类与类之间的关系和交互，在有些场合，一张协作图就完全能够反映出实际用例的协作画面，而在另一些场合，只有把三种不同的图结合起来，才能反映协作状况。
（3）协作的实例---脚本
脚本是用例的一次具体执行过程，它代表了用例的一种使用方法，当把脚本看作用例的实例时，对角色而言，只需描述脚本的外部行为，也就是说能够完成什么样的功能，而忽略完成该脚本的具体细节，从而达到帮助用户理解用例含义的目的；当把脚本看作协作的实例时，则要描述脚本的具体实现细节。
实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类，类的操作和类之间的关系。具体说来，就是把用例中每个步骤所完成的工作交给协作中的类来完成。实质上，每个步骤转换成类的操作，一个类中可以由多个操作，注意，一个类可以用例实现多个用例，也就是，一个类可以集成多种角色。
用例和它的实现之间的关系可以用精化关系（图示为带箭头的点画线）表示，也可以用case工具中的不可见的超链接实现。
uml创始人定义了三种类型的版类对象类，边界对象（接口对象），控制对象和实体对象
（1）边界对象
这种对象类紧靠系统的边界，它负责与系统外部的角色交互，在角色和系统内部的其他对象类之间传递消息
（2）控制对象
这种对象类控制一组对象之间的交互，控制对象可以是刺激用例启动的角色，也可以用来实现若干个用例的普通序列，控制对象通常仅存在于用例执行阶段。
（3）实体对象
这种对象类代表系统控制区域的区域实体，它是被动对象，本身不能启动交互，在信息系统中，实体对象通常是持久的，存储在数据库中，实体对象也可以出现在多个用例中。
