用例图（复习）

因为UMl视频是那样看的，更没有认真总结，到后面的一系列画图，各种困难，当时欠的全都还给我了，亡羊补牢吧。

用例图。

要素：角色、用例、联系，边界（rose中木有）。

参与者和角色。

先抛开用例图说参与者，我们拿小说来说吧，参与者不仅是小说故事中的主人公，也是配角，丑角，也包括写书人，也包括看小说的人。是有了人物才有了故事，而不是有了故事才有人物，人物是故事的驱动，小说中的每个主人公的存在都有他的意义，每个主人公都有他的故事，每个故事都有一定的寓意，每个寓意就是写书人想要达到的效果，实现这些功能，需要的参与者。用例设计的三要素第一就是参与者，用例，联系。而我们平时所说的角色是把参与者抽象出来的，角色是类，参与者就是对象了。机房收费系统中的三种角色是参与者，学生也是参与者，由于学生这个参与者对系统的一些驱动操作是有用户角色代替的，所以学生可以画到用例图中，也可以不用画到用例图中。

很多资料上说用例上的小人是参与者，其实不是参与者，是角色的。

参与者（或角色）也是独立的，不是一个参与者依赖于另一个参与者。参与者是对系统直接并主动的发出动作并获得系统的反馈的，否则就不是参与者。

机房收费系统可以抽象出五个角色：一般用户，操作员，管理员，学生，DB Server。

用例。

对于我们开发人员来说就是需求，对于系统来说就是该系统的功能。

大象中是这样说的，一个完整的用例的的定义，由参与者，前置条件，场景，后置条件构成。怎样去理解呢，就拿生活中一个简单的例子来说吧，我们要去超市买好吃的，参与者是我，前置条件，一是我们要选择不同的路去元辰，在西院没封的时候，我们有很多条路，走每一条路就是一个场景，当我们买完东西要付款的时候，我们带的钱是否足够可以支付，只有我们带着足够的钱并支付完毕，才完成我们“去元辰购物”这一用例。

再拿我们机房收费系统的用户登录来说也是一样的，需要密码和用户名，只有密码和用户名全部正确才能成功登录，这里面出现的用户名错误，密码错误，输入为空，或是输入的不否和输入要求的等各种情况就是场景，“用户登录”用例。

用例表达的是系统参与则的愿望，是由参与者启动的，不存在没有参与者的用例，比如我们刚才说的去元辰买东西，是我驱动的这个事件。

用例是有动宾短语组成的，例如机房收费系统中的修改密码这一个用例，就不能命名为修改这个动词。

边界。

角度不同边界不同，就像昨天看的图书馆的服务器一样，在表面看来是个大的箱子，如果拆卡来看就看到的是内部的零件了。大象中说边界决定抽象层次，要灵活使用。

画用例图具体见：http://xhf123456789plain.blog.163.com/blog/static/172880482201192221826110/

用例图中的四种关系。

关联，泛化，扩展，包含。

主要说说扩展和包含的关系，月姐在看我的用例图时问到了这一点，当时回答的很牵强，是没有深刻的理解。

扩展是两个用例没有根本上的联系，就像是书和书架，那样，书是可以离开书架的，而包含的关系就像是人体的肢体和我们本身，我们本身是包括肢体的，将像机房收费系统里的结账用例，可以划分为几个细的用例，这几个细的用例就是包含关系，购卡统计，充值统计，还有退卡统计，这都是在结账中必须包括的，而对于用户的管理中有一个删除和添加用户就不一定了，用户管理，中可能是对用户删除也可能是对用户进行添加操作，所以不是必然情况。其实包含和扩展关系，就像是我们学的初中的一个数学知识，包含是，一个条件是另一个条件的充要（既是必要条件也是充分条件）条件，而扩展是必要不充分条件。又如，用户登录也只有登录上去，才能进行其他的用例操作，如果没有登录进去，就不能实现任何需求。所以其他的用例和用户登录用例都是包含关系的。

1，用例有大小之分用包含。

2，用例有先后之分用扩展。

3，用例有父子之分用泛化。

上述三条总结引自：ZS的博客。理解的比较的深入，说说最后一条泛化关系吧，就是子类可以替代父类就是泛化关系，如下图中所示

电话预定用例可以替代预定用例，网上预定用例也可以替代预定用例。

XXY的博客也有详细的步骤。

最后说说画图要注意的事项：

1、用例图中无论是角色还是用例最好要用英文来标记，因为中文很肯能会出现乱码。

2、粒度的划分上，粗粒度和细粒度是有区别的，要根据开发项目的大小和需求来分，我认为粒度越详细越好，用例是和BLL层对应的。