浅谈UML用例建模
这段时间在写自己的项目，并且我认为这是一个非常宏伟的事情，我对它充满信心。它将给现在我们的学习结构发生一些变化。我最近在写文档，以前不怎么喜欢写文档，因为我不把写文档当做一件有技术含量的事情，直到这个学期学习了刘伟的课。我对文档的认识发生了质的变化，我要写文档，而且还要写得好。
用例建模是在进行业务建模过程中一个非常重要的部分，是明确系统功能模块的关键。
用例建模（Use Case Modeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。
其中用例建模的主要包括用例图和用例文档，其中我感觉写用例文档是一件比较烦躁的事情，但是它却可以清楚的表述出你的系统每个模块的业务规则。用例建模的基本过程有：
1、识别执行者
2、识别用例
3、绘制用例图
4、编写用例文档
5、检查用例模型
1、识别执行者
执行的的定义是：
在系统之外，透过系统边界与系统进行有意义交互的任何事物。通俗的来讲也就是
谁使用了系统？
系统需要和哪些外部系统交互？
有没有自动发生的事件？
也就是说执行者不仅仅是人，也可能是其他系统或者是自动发生的事件。识别执行者的目的是为了确定系统边界。
执行者用一个小人表示：
2、识别用例
用例的定义是：用例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。
用下面符号表示：
其中用例必须是有意义的目标，要由系统产生一定的价值，用例不能使操作步骤，比如我们要对商品进行查询，我们不能做出这样的用例：
实际上我们应该这样画：
再者我们要时时记着我们用例建模的目的是为了进行需求建模产生的SRS(需求规格说明书)让用户看的，我们要使用通俗的业务语言而避免使用想JAVA,数据库，C++这样的专业术语，因为用户有可能并不是计算机专业人员。
在写用例时我们应该使用：
（状语） 动词 （＋ （定语）宾语）的结构
在编写用例的时候我们要合理规划用例的粒度：
1、我们要避免把参与者执行的步骤当做用例，比如下面这种错误的做法：
2、我们不能把系统活动当做用例，比如下面：
3、我们还要防范用例中的泛滥正删改查操作：
用例中出现增删改查操作固然正确但是却造成了用例泛滥，我们倒不如用以下方式：
这种方式囊括了用户的增删该查操作，很好的减少了用例的个数。
---------------------------------------------------低调的分割线---------------------------------------------------------
用例图中元组的关系：
执行者与用例之间是关联关系（Association）。
执行者之间可以有泛化关系（Generalization）。
需要注意的是用例与用例之间的关系还是比较复杂的，
1、包含关系
描述在多个用例中都有的公共行为，由用例A指向用例B，表示用例A中使用了用例B中的行为或功能，包含关系是通过在依赖关系上应用<<include>>构造型（衍型）来表示的。
2、扩展关系：
扩展关系就是指可以在基用例上添加新的行为，但是基用例必须声明某些特定的”扩展点“，并且扩展用例只能在这些扩展点上扩展新的行为。
3.泛化关系
当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。
在以后的博客中会结合大神老师上课的例子来具体讨论UML用例的。