实战项目之用例图
=================================用例图简介====================================
用例图就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。
用例图（User Case）是被称为参与者的外部用户所能观察到的系统功能的模型图，呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。用例图用于对系统、子系统或类的行为进行可视化，使用户能够理解如何使用这些元素，并使开发者能够实现这些元素。
将每个系统中的用户分出工作状态的属性和工作内容，方便建模，防止功能重复和多余的类。
用例图定义了系统的功能需求，它是从系统的外部看系统功能，并不描述系统内部对功能的具体实现。
=======================万事开头难，用例图很重要=========================
我们都应该知道在实际的软件项目中，一个软件要实现的功能是通过用例来获得的。接下来的所有的分析、设计、实现、测试都由用例来驱动的，即以实现用例为目标，这就是所谓的用例驱动。
用例驱动原理告诉我们，我们如果要解决问题领域就要归纳出合理的抽象角度（用例），为这些用例描述出可能的特定的场景，并找到这些场景的事物、规则和行为
所以，如果一个工程用例图画不好，那么以后的分析、设计、实现到测试都会收到影响；并且我们所研究的问题领域也是解决不了的。
=============================工欲善其事 必先利其器============================
要想画好用例图，就要“工欲善其事 必先利其”。所以我们必须对一些建模元素相当熟悉。
下面介绍几个比较重要而且是经常使用的建模元素。
版型：版型是对UML元素基本定义的扩展，在同一个元素基本定义的基础上赋予特定含义，使得这个元素能够适用于特定场合。UML中几乎每一个元素都有很多版型，如接口类、边界类、实现类等。
我们知道版型概念后，下面介绍参与者的几个版型：
参与者：
参与者是在系统之外与系统交互的某人或某事物。我们在寻找参与者的时候，要注意一个边界的概念（这个概念随后介绍），因为参与者是在系统之外，所以理所当然系统会被一个边界包裹者，这是我们必须要知道的。
我们有时候寻找参与者的时候，总是遇到这样和那样的问题，总是在问“他是不是参与者”、“到底怎样判断他是不是”。有一本《大象—thinking in the UML》中教给我我们如何寻找参与者：
a) 谁对系统有着明确的目标和要求并且主动发出动作？
b) 系统是为谁服务的？
读者可以尝试着用这两个问题来解决寻找参与者的困难。相信你会有以外发现的哦！
参与者的一个版型：业务主角
首先说这个元素是在需求阶段使用，是定义业务的参与者，它是确定业务范围的，它是针对业务人员而不是计算机用户。
我们知道，如果要建设一个符合客户需求的计算机系统，我们就要完全彻底的搞清楚客户的业务。所以这时候业务主角是非常重要的。
参与者的另一个版型：业务工人
业务工人参与了业务，但是是被动参与业务的，他没有什么具体目的，但是他在业务中作了自己的事情。
《大象》中也给出了判断是不是业务工人的方法
a) 他是主动想系统发出动作的吗
b) 它有完整的业务目标吗
c) 系统是为他服务的吗
用例：
用例定义了一组用例实例，其中每个实例都是系统执行的一系列操作，这些操作生成特定主角可以观测的值。
用例是相当重要的一个元素，因为我们知道面向对象所有的东西都是封装起来的，大家谁也不理睬谁，只有在外力的施加下，各个类才发生作用，而这个外力就是我们的用例。
用例的版型：业务用例
业务用例是用于需求阶段的业务建模，主要是说明客户的业务是怎么来建立模型的。如果说用例是用来获取功能性需求，那么可以说业务用例用来获取功能性业务的。（值得注意一点的是这个业务用例的建模是和计算机系统建模无关的，他主要真的是业务）
用例的另一个版型：业务用例实现
业务用例实现是业务用例的一种实现，一个业务用例可以有多种实现，同理一个业务用例的多个业务用例实现是为了达成统一目的。
用例的另一个版型：系统用例实现（是系统用例的一种实现）
边界（这个在rose中是没有定义的）：
如果大家对封装的概念了解了，那么边界也就清楚了，他俩其实是一样的。
到此位置，我们就可以开始实战用例图了。革命尚未成功，战士尚需努力！！！
=================================实战，你行的！================================
第一步：了解业务概况（系统是机房收费系统）
学生上机：学生首先要注册，之后上机，学生卡里没钱可以充值，当然以后不想上机可以退卡；学生也可以查看余额、充值记录、上机记录等
系统管理者：可以添加系统用户和删除系统用户，当然也可查看工作记录，查看学生上机和消费的一些记录，设置系统参数和日周结报表等
第二步：整理业务目标
这里一般是客户提出的。
a) 财务管理服务业务---规范化财务管理，提高效率，减少人为差错
b) 上机学生服务业务---为上机学生用户提供业务办理自动化服务，提高办事效率，方便客户，为客户提供更好的服务
c) 系统管理服务业务---合理管理系统设置，管理业务服务部门的用人分配，让系统稳定有序高效的运行
第三步：分析涉众
涉众是与要建设的业务系统相关的一切人和事。分析涉众要从业主、业务提出者、业务管理者、业务执行者、承包方、法律等等方面分析
机房收费系统涉及到的涉众有操作员、管理员、一般用户、学生用户、业务服务部门、学院财务管理、学院领导等（笔者在这里不全部列出来了）
第四步：边界分析
财务管理服务业务边界
上机学生服务业务边界
系统管理服务业务边界
第五步：业务分析：业务用例和业务主角分析
业务主角：
财务管理服务业务主角：
上机学生服务业务主角：
系统管理服务业务主角：
业务用例分析：
财务管理服务业务用例
学生上机服务业务用例
系统管理服务业务用例
第六步：系统分析：系统用户、系统用例、系统用例实现
系统用户：
系统用例：
财务管理服务系统用例：
上机学生服务系统用例：
系统管理服务系统用例：
系统用例实现：
财务管理服务用例实现：
上机学生服务用例实现：
系统管理服务用例实现：
======================================笔者希冀=================================
UML不是一天就能将它学的很好，因为世界上几乎没有一个人知道了“马走日象走田”，就能在象棋艺术中百战百胜。
所以我们要在每一个项目中学习，锻炼，并且进步。
用心去思考，用心去沉淀，每次进行项目实战都要收获知识和经验。
最后：这个项目的一些图画的也会有疏漏，希望读者给指出，你的指正是我进步的最大动力！谢谢！