【转载】用例图 usr case

用例图是用来描述什么角色通过某某系统能做什么事情的图，用例图关系的是系统的外在表现，系统与人的交互，系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义： 
小人： 
对使用某系统的用户进行分类后，可以总结出使用本系统有哪些角色，不同的角色的工作责任不太一样，他们需要用到的系统的功能也会不太一样。 
小人就是角色，它给了我们一个启示，我们思考某系统的需求时，可从不同角色的角度来思考。 
例如：我们要做一个考勤系统，你会怎样思考呢？会一下子列出很多功能？比较好的方式，应该是先思考什么人会用这个系统，我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统，对于一般员工来说除了打卡，他还关注什么？对于前台，她是不是要做一些考勤的统计？而财务是不是要根据考勤情况来调整员工的薪金？这样的思考方式，会让我们更容易全面发掘系统的需求。 
还需要特别说明的是：角色可能是人，也可能不是人，而是另外的一个系统，本系统与另外一个系统交互的话，可以将另外一个系统画成某某角色。 
圈圈： 
圈圈里面会有一段动宾结构的文字，也就是“动词+名词”这样的方式，这个圈圈+圈圈里面的文字，就是用例，这些用例表明了系统能做什么事情。 
以考勤系统为例：有两个用例叫“打卡”、“查看自己的考勤情况”，这个两个圈圈分别用一条线连到了“一般员工”这个角色，我们可以按这样的顺序来读这个图：先读出角色的名字，然后读出用例中的文字。按着这样的读法，我们可以得到两句完整的句子： 
“一般员工打卡” 
“一般员工查看自己的考勤情况” 
大家可以用这样的方式来检查自己用例图是否画得合适。 
某用例不一定是只属于某个角色的，有不少用例是多个角色“共享”的。 
大框框： 
在所有用例的外面，有一个方框，这个方框只框住了用例，没有框住角色，这个东西就叫做系统边界，框框的上部会注明本系统的名字。 
我们所做的系统，是不可能包括角色的，系统要发挥各种作用，要靠各角色“穿越”系统边界来使用本系统的用例。 
系统边界能清晰表达出系统的范围，并不是所有的用例图都需要画出系统边界的，一般只需要在全局用例图中画出系统边界，当对用例进行细化时，不需要画出系统边界。 
线条： 
线条是指角色与用例之间的线条，线条有三种：无箭头的，指向用例的箭头，指向角色的箭头。无论是否有箭头，这些线条是用来联系角色（小人）和用例（圈圈）的，表示某某角色能“做”什么用例。 
有箭头的线条，表示角色与系统交互的过程中，数据的流向，如果箭头指向用例，就说明角色需要往系统输入数据，如果箭头指向角色，说明系统往角色输出数据。 
而没有箭头的线条，则没有明确表示数据的流向，一般情况下不需要明确表示数据的流向，只需要画无箭头的线条就可以了。

用例图中的Extend、Include、继承

“打印报表”这个用例有一条指向“查看一般报表”用例的虚线，虚线上有“<<extend>>”的字样，这表示“打印报表”扩展了“查看一般报表”，用户可以在“打印报表”的基础上做“打印报表”的工作，这就是Extend的意思。如果“打印报表”这个用例不存在，是不会影响“查看一般报表”这个用例的，而“查看一般报表”这个用例如果不存在，则用户无法在“查看一般报表”的基础上做“打印报表”的工作了。 
“管理数据”有三根虚线，箭头分别指向“查看数据”、“新增数据”、“修改数据”，虚线上有“<<include>>”字眼，这表示“管理数据”包含“查看数据”、“新增数据”、“修改数据”三个子用例，这就是Include的意思。在以下情况下，会用到Include： 
1)某些用例的其中一些步骤可以单独抽离出来，成为一个子用例。 
2)以“树”的方式条理化各种用例，用Include来组织好父子用例，子用例可以再次Include自己的子用例。 
上图中将“管理数据”进一步分解为子用例，其实是没有必要的，实际项目中数据的查看、增加、修改、删除操作是很常见的，我们在描述用例的时候一般只需要将这4种操作说成“管理XX”就可以了。 
细心的朋友可能会发现，角色与角色之间怎么会有一个类图中的“继承”符号呢？从上图看来，就是录入员继承一般用户，领导继承录入员，什么意思呢？ 
无论是录入员还是领导，都需要先登录系统，才能使用各种功能，我们是否需要分别在“登录用户”与“录入员”、“领导”之间各拉一条线？ 
一般用户可以查看一般报表、打印报表，那么录入员、领导是否也可以呢？ 
录入员这个角色继承了一般用户，其实就是表示一般用户能做的事情，录入员也能做，同意道理，录入员能做的事情，领导也能做，这个“继承”符号就是这个意思。在实际工作中，我们往往需要用好这个“继承”符号，将角色进行适当的抽象。

用例图何时需要分解、何时不需要分解？ 
也就是分解的粒度通常情况下是多大呢？

用例的表达粒度是由自己控制的，以下几点建议供参考： 
1.在客户能准确全面理解的基础上，用例约精简越好。 
2.重点难点用例，应详细去描述。 
3.用例需要开发人员去实现，要让开发人员能看懂。 
4.用例图不是万能的，也不是表达需求的唯一方式，我往往会以用例图为主同时附加其它的表达方式来表达，某些特殊项目，我甚至不用用例图来描述需求。