一：什么是用例
举例：我要买一部智能手机，但是怎么在众多的手机当中选择适合自己的那一款呢？我会问我自己，我要什么配置的？什么样的操作系统，什么样的CPU型号，什么样的CPU频率、网络制式等，手机的像素是否能满意我的要求？手机的照相功能是不是能美化照片等等。我们都有过这样的经历，这种经历就是用例分析。
这个过程在系统开发的分析阶段非常重要，用户对系统的使用方式决定了系统如何设计与构造。用例就是从用户的角度出发，对如何使用系统的描述。可以认为用例是系统的一组使用场景。每个场景描述了一个事件。
举例：饮料销售机。饮拿出料销售机的主要功能主要是允许一个顾客购买一罐饮料，你马上就会想到有关的场景（换句话说就是用例），这个场景暂且叫做“买饮料”。这个用例的参与者是买饮料的顾客。顾客将钱插入销售机触发这个用例的场景被执行，如果一切顺利，销售机会自动这种饮料给顾客。该场景其它方面也值得考虑。顾客发起“买饮料”这个用例的执行场景的前置条件是顾客感到口渴，场景执行完成之后的后置条件是顾客有了一罐饮料。
在“买饮料”这个用例中，正如我刚刚所说的，如果一切顺利，顾客会获得一罐饮料，那如果不顺利呢，意外一：销售机没有这种饮料，那么销售机会给顾客一个提示：没有这种品牌的饮料。理想情况下，销售机会提供两种选项，一是让顾客选择另一种饮料，二是让顾客取回原来的钱。该场景的前置条件是用户感到口渴后置条件是顾客得到一罐饮料或者顾客投入的钱被退回。意外二：如果机器中刚好存有适合的零钱，那么机器会退还零钱并交付饮料。如果没有零钱，它将退还钱，并显示一条消息提示顾客投入适当的零钱。前置条件和前边场景都一样，后置条件是顾客得到一罐饮料或找回零钱或按原款归还。总之这些场景也是”买饮料“，可以把这个场景看成是用例执行时的一条可选路径。
那还有没有其它场景呢?当然有，供货人负责为销售机提供饮料，收款人负责定期收集销售机中的钱。这说明至少还需要建立两个用流利：“供货”和“收钱”。当导出一个用例时，不必关心怎么实现它，我们只是试图查明饮料销售机对使用它的用户来说是什么样子。用例的详细程度要能正确反映用户的需求。
二、用例之间的关系。
用例之间主要是关联、依赖、泛化关系。在依赖中会有包含和扩展。
包含：在饮料销售机中，有“供货”和“收钱”两个用例，也许你会注意到一些相同的步骤，两个用例都以打开机器为起点，以关闭和锁好机器为终止点。能不能消除用例中重复步骤呢？方法是从各个步骤序列中抽取公共步骤形成一个每个用例都要使用的附加用例，即新的用例，打开机器可以形成一个新的用例为“打开销售机”，关闭机器形成一个新的用例为“关闭销售机”，那么在“供货”好“收钱”这两个用例中都包含了新的用例。这种用例的复用技术被称为包含用例，它们之间的关系就叫做包含。可视化的表示是在虚线上方标注为两个尖括号括起来的“include”。
扩展：供货员在供货的时候会注意到有些品牌的饮料销售的好，有些品牌的饮料销售的不好，在这种情况下，销售员不是简单的把所有饮料都补充给机器，而是把销售不好的取出来，用销售好的来代替它们。而且在机器前修改饮料品种的指示牌。我们把这些步骤加入到已经建立的“供货”用例中，我们会得到一个新的用例，可以称为“根据销售情况供货”。这个新用例是对原用例的扩展，这种技术叫做扩展用例。它们的关系就要扩展。可视化的表示是自虚线上添加一个用双尖括号括起来的“extend”表示。
泛化：就比较简单了，如果这台饮料销售机允许顾客选择一罐饮料或是买一杯饮料。在这种情况下，买饮料就是一个父用例，买一杯饮料和买一罐饮料就是子用例，子用例可以从父用例继承行含义和行为，还可以自己增加行为。任何父用例出现的地方子用例也可以出现。可视化的表示是用一条带空心三角形箭头的实线从子用例指向父用例。
三、用例图
将参与者和用例关联起来的可视化模型就是一幅用例图。以机房收费系统为例，下面是我的用例图：
