UML—用例图
用例图（use case diagram）：是系统的蓝图，是系统开发的依据。
概念：描述了作为一个外部观察的视角对系统的印象。强调这个系统干什么，而不是怎么工作。 显然用例图用于软件设计的需求分析阶段，描述了一个待开发系统的功能，以及是有哪些执行者执行的这些功能的。
构成成分：角色、用例、关系。
角色（acter): 和SQL中角色一样，是一组相同权限的集合。也就是不同的角色可以使用不同的功能。
用例（use case）：捕获用户需求，完成一个具体的用户目标。
一句话解释：一个具体的用例代表了一个具体的功能。
关系（relation）：描述角色和用例之间的关系。显然是角色和用例之间连接的桥梁。
UML中的关系：关联关系、泛化关系、包含关系、扩展关系。
关联关系：通常用管理关系描述描述参与者和用例
泛化关系：子用例是父用例的特殊形式。例如机房收费系统中的打印（父用例）他的两个子用例分别为日结账打印和周结账打印。
包含关系：一个用例的行为包含了另个一个用例的行为。例如机房收费系统中上机管理包含部分下机和全部下机。
扩展关系：一个用例也可以被定义为基础用例的增量扩展。就是把新的行为插入到已有的用例方法中。例如小明去图书馆借阅图书，当然有归还这一个功能（即归还图书这个用例）如果没有按时间归还，可以增加一个扩展用例—缴费罚款用例。
既然用例图描述一个系统是做什么的？那么用例多了会显得系统复杂，少了，导致对系统的维护难度加大。这就需要控制好用例图的粒度和范围。
用例分析是以参与者为中心，例如小明去图书馆借书，步骤：（查询数目—出示借书证—管理员查询小明的借阅记录——借书成功）小明借书需要这么多步骤，难道要用这么多用例么？用例是参与者的唯一具体的目标，小明的唯一，以及最终具体的目的就是借书。
下面我们以机房收费系统为例，画出用例图。
管理员：
一般用户
用例图的作用：分析人员使用用例图来描述用户的需求，与用户和设计人员交流，最终用户使用用例视图来理解要完成的系统的功能，确认是否符合自己的要求，测试人员根据用例图来验证实现后的系统是否符合用户的需求。用例图从一定程度上驱动了需求分析后各个阶段的开发工作。
具体概括为三点：1.重在应用 2.重在交流 3.重在事件流的描述
用例图是软件需求分析到最终实现的第一步，它描述了一个系统是做什么的，是一个完美高质量软件的起点。
以上就是我对用例图的看法，希望大家提过宝贵的建议，您的建议就是我收到的最好的礼物！
其它总结：