UML之用例建模

这几天一直在看UML的东西，现在算一个阶段。就随便写点东西，也算是对自己的一个交代

UML作为面向对象的统一建模语言，对软件的开发设计起到决定性影响，特别是一些大型新的事务关系复杂的项目直接关系到项目的成败。通过建模对开发项目进行良好灵活的设计是日后成功开发的基础。

<o:p></o:p> 

用例建模：

<o:p></o:p> 

   首先对开发项目进行需求分析，得到其需求描述，这时，使用用例来描述系统的需求是一个比较好的办法，可以将业务需求和内部设计很好的区分开来，避免需求过于细化，以至于涉及到内部设计方面的内容，导致系统需求分析过于复杂化（这个问题在以前学校开发项目是最头疼的问题之一）。使用用例图来清楚的描述系统的需求。<o:p></o:p>

    对得到的用例需求进行概要描述，补充相关内容，这样，就可以从中得到系统的分析类，可以基本确定系统所涉及到的类，画出基本类图（以前总是搞不清楚类到底咋来的，自己觉得需要就新创建一个，但没有理论支持，自己都不能说服自己，现在终于可以给自己一个比较满意的答复）。<o:p></o:p>

    得到这些分析类有一个简单的方法：对需求分析中名词（形容词＋名词）进行筛选，然后对筛选出来的名词提出几个问题进行测试，如果符合，那么它就有可能成为所需要的分析类或成为类属性。然后使用职责驱动的方法对分析类进行充实（定义类在业务中的职责、使命，描述了类对外提供的服务，本身数据和操作都是服从于某些目标和职责的）。虽然要很好的做到这点并不容易。但对于以后的经验的积累和对系统设计的理解都有很大的好处。相信以后这点可以成为一个设计习惯而保持，对自己以后对项目的理解有很大帮助。<o:p></o:p>

                     得到以上信息后，我们就可以使用类（序列图中使用类进行流程分析）对用例进行详细的描述，可以利用序列图（时间）、活动图（活动）和协作图（空间）来实现这些需求。<o:p></o:p>

              <o:p></o:p>

     至此，对UML中几种常用的建模用图有了比较清楚的掌握，何时用那种图进行建模，以及使用该图的原因都有了明确的认识。<o:p></o:p>

<o:p> </o:p>

    以上是对UML建模的一个整体的认识，对于各种图的基本知识点也有明确，例如：<o:p></o:p>

    用例图：包括参与者，用例，通讯关系<o:p></o:p>

            寻找参与者：<o:p></o:p>

Ø         谁使用系统<o:p></o:p>

Ø         系统从谁或别的系统获得数据<o:p></o:p>

Ø         谁或别的系统为系统提供数据<o:p></o:p>

Ø         系统和其他系统的关系<o:p></o:p>

Ø         系统由谁来管理和维护<o:p></o:p>

时钟系统（对周期性系统来说是一个特殊的参与者）<o:p></o:p>

参与者的关系：泛化或继承关系<o:p></o:p>

用例之间的关系：包含、泛化、扩展<o:p></o:p>

 其他的就不再多说了，有点懒，呵呵