UML 概述及用例图

《UML 精粹》读书笔记。读的是老版，可能和你了解的有一些语法上的不一致

UML 全称为统一建模语言，它不是一种方法，而是一种语言，跨越了具体编程语言的限制，以其当前状态定义了一种表示法和一种元模型。

为什么需要 UML

首先需要明白一点，任何一种工具的出现都是为了解决某个实际问题的，而这个工具自身的生命力还很强，那就说明它解决问题的效果很棒，至少当前没有找到比这一工具更有效率的替代物。

软件开发最大的挑战是构建正常的系统，即满足用户且价格合适的系统，这看起来是很容易的事情，但实际做起来却相当困难，我们必须用我们熟悉的行话与用户沟通，而用户却使用他们自己更为神秘的行话（比如医疗术语等），所以实现良好沟通乃是开发良好软件的关键。

UML 就是要解决此前面向对象设计方法中表述不严谨、沟通效率低的问题。如果我们使用自然语言来描述某个比较复杂的概念，很容易就会引起大家的困惑，可能自然就想到相应的代码是非常精确的表述，但是又过于详细了。因此，当需要一定程度的精确性同时又不失掉细节时，UML 便是非常好的选择。

概要开发过程

UML 是一种建模语言，但是如果不了解建模技术如何适应过程，那么建模技术也就不会有丝毫的意义了，UML 是独立于过程的，它可以适用于任何过程。

一个软件的开发过程中大致会遇到四类风险。1、需求风险：你将开发一个错误的系统，压根就不是客户想要的系统；2、技术风险：如何把各个设计成分组合在一起（比如 C++ 和数据库）；3、技艺风险：能否得到所需要的工作班子及专门的知识；4、政治风险：存在可能妨碍并严重影响项目的政治力量。

针对需求风险，我们可以通过用例来驱动开发，但是需要注意的是，用例并不是整个形象，所以另一个重要的任务就是提出领域概念模型，为了防止开发出错误的系统，需要经常和领域专家进行沟通，去熟悉领域的专业知识，同时能获得很多的用例也是关键。

最大的技术风险在于如何把各个设计成分组合在一起，比如你很了解 C++ 和关系型数据库，但是把它们放在一起的时候就很难保证不出问题，所以在设计时可以给自己提一些问题：如果技术的一部分不能工作，将要发生什么？某件事做错的可能性是什么？如果错误发生，将如何应对？

应对技艺风险最切实可行的办法就是组织读书小组，几个人读同样的一本书，约定每周读几章，然后花一两个小时讨论，这是很有效的一个模式。同时自己也需要放开眼界，留意自己在技艺或经验不足的方面。如果有一个知识渊博且妙趣横生的人作为导师，那即使付一笔酬金也是值得的，获得面向对象技艺的最佳办法就是导师指导。

技术人可能对付政治风险都会乏力，最简单的办法就是消除领导的不确定性，给领导制定一个详细的迭代计划，辨认出所有的重要风险并且知道如何应对这些风险。简而言之就是给领导呈交一个详细的计划表。

用例图

不管是在面向对象或是传统开发界中，人们都使用典型的交互来帮助了解需求，通过用户使用场景去获取需求，用例就是以文本形式从用户角度描述系统的行为，为了使用例更加形象化，Jacobson 也引进了用例图，它是用来描述参与者与用例以及用例与用例之间关系的图，即```用例图 = 参与者 + 用例 + 关系。

上文公式中已经给出了用例图的基本元素，即参与者、用例和关系。参与者是用户相对于系统而言所扮演的角色，虽然我们都会把参与者画成一个小人的形状，但它不仅它可以是人，也可以是其它外界系统，并且每个参与者可以参与一个或多个用例，参与者是用例的启动者，需要要注意的是参与者并不是系统的一部分。

参与者与用例之间有天然的关系，除了这种关联关系之外，用例之间可以有包含关系，比如价格交易和风险分析都要求交易定价，而且表述交易定价涉及到相当分量的文字工作，针对这种情况就可以表述一个独立的「交易定价」，并在原来的用例中引用它。

有时候一个用例和另一个用例很相似，但是其作用又略大时，可以使用泛化关系，你可以通俗的将其理解为面向对象中的继承关系，子用例继承父用例中的一切。泛化关系不仅适用于用例，也适用于参与者，在实线上加上空心的箭头就表示泛化关系。

我们还有一个和泛化关系类似的扩展关系，但是它的规则更多一些。可以通过扩展用例向基用例中添加额外的行为来扩展基用例的功能，这时基用例必须说明一些「扩张点」，而且扩展用例只能在扩张点处增加补充行为。一个用例可以有多个扩张点，并且一个扩展用例也可以在一个或多个扩张点处扩张。

我们好像忘了一个系统边界的概念，因为一个系统中的每一个功能都有它的所属范围，划分系统边界对于决定系统规模和分配责任是十分重要的，在 UML 中使用矩形框来表达系统的边界，在其左上方放置系统的名字。

参考内容：用例图详解