UML学习笔记
在UML系统开发中有三个主要的模型：
功能模型: 从用户的角度展示系统的功能，包括用例图。 对象模型: 采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类图、对象图、包图。 动态模型: 展现系统的内部行为。 包括序列图，活动图，状态图。
UML用例图
什么是UML 用例图？（what）
用例图从外部用户的角度捕获系统的行为。他将系统功能划分为对活动者具有意义的事务。
用例图展示了一个外部用户能够观察到的系统功能模型图。
用例图是由用例、角色和关系三部分构成的。其中比较关键的是用例和角色，而关系是连接角色和用例之间的桥梁，表明用例的角色之间的关系。
举个栗子：银行用户的用例图
为什么画UML 用例图？（why）
用例图用于需求分析阶段，获取系统的外观图。描述了一个待开发系统的功能需求，用例图是用来收集系统的要求，包括内部和外部的影响。用例视图强调的是系统的功能，是软件开发设计过程第一个设计的视图。
它从用户的角度描述用户的雪球，从而描述系统的功能，并指出各功能的执行者，以及执行者完成了哪些功能。所以，分析一个系统时要收集其功能用例和确定参与者。
用例图常常用于项目初始，分析用户需求的阶段。
- 用户：通过用例图与设计人员交流，用户使用用例视图来理解要完成的系统的功能，确认是否符合自己的要求。
- 产品团队：不用管怎么实现具体的功能，只要能向客户形象化的表述项目的功能就行。
- 开发团队：通过用例图以一种可视化的方式理解系统的功能需求。
- 测试团队：根据用例图来验证实现后的系统是否符合用户的需求。
因此，用例图从一定程度上驱动了需求分析后各个阶段的开发工作！
如何画UML 用例图？(how)
参与者可以是人的用户，一些内部的应用程序，或可能会有一些外部应用程序。因此，在一个简短的，当我们正计划绘制一个用例图中应该有以下项目:
- 功能被表示为一个用例
- 参与者
- 用例和参与者之间的关系。
一个系统怎样寻找参与者呢？要看谁使用系统的这种功能，谁来维护这个系统，系统需要与哪些硬件交互，系统需要操作哪些硬件。而寻找功能的原则是把系统看成一个黑盒子，从外部执行者用户的角度理解系统，不需要考虑功能是如何实现的，只需考虑系统需要有哪些功能，功能由谁交互和执行。
绘制到用例图捕获系统的功能要求。因此，确定上述项目后，我们必须遵循以下指导原则，绘制一个有效的用例图。
- 一个用例的名称是非常重要的。所以名的选择应以这样的方式，以便它可以识别执行的功能。
- 给出一个合适的名参与者。
- 图中清楚地显示关系和依赖性。
- 不要试图包括所有类型的关系。由于该图的主要目的是确定要求。
- 使用注意以往任何时候都需要阐明一些重要的点。
如何画出一个好的用例图？
要想成为一个良好的用例图，如果用例过多，会导致系统过于复杂，而用例过少，会导致对系统的维护难度加大。这就需要控制好用例图的粒度和范围。从用例图的属性着手，准确的画好用例图。
用例图的好坏影响代码的实现难度和系统修补难度，用例图要和后面的其他视图相互关联起来，所以要给出良好的用例的粒度。
用例图还应注意清晰的定义系统边界，从执行者的角度来命名用例，避免与执行者的名字不一致，避免与执行者之间的关系太复杂等。用例可以很好的描述系统需求，但是有些场合用例来描述是不适合的，这就需要用来文档描述，
再举个栗子：用户信息管理系统
可以补充下画用例图的工具之类的东西。
