think in UML（二）

基础篇——在学习中思考！

在大概了解了UML之后就该系统的学习UML的主要建模元素了，一个个实例帮助我们更好的理解这些元素的重要性并运用相关知识解决实际问题。

在UML里有一个概念叫版型，有些书里也称为类型、构造型。版型只是UML的一种扩展手段，本身并不涉及太多的思想和方法，而是在建模的不同阶段，为了区分视图之间的不同观点，会采用不同的图示来表示。

以人为本是当代的流行词汇，UML建模也是以人为本的。参与者在建模过程中是处于核心地位的，actor是在系统之外与子同交互的某人或某事。系统之外的定义说明在参与者和系统之间有一个明确的边界，赞誉这只可能存在于边界之外，边界之内的人和事物都不是参与者。在查找参与者的过程中，可以询问以下问题以帮助确定参与者：

（1）谁是负责提供、使用或删除信息？

（2）谁将使用此功能？

（3）谁对某个特定的功能感兴趣？

（4）在组织的什么地方使用系统？

（5）谁负责支持和维护系统？

（6）系统有哪些外部资源？

（7）其他还有那些系统需要与该系统交互？

查找参与者时请注意，参与者一定是直接并且主动的向系统发出动作并获得反馈的，否则就不是参与者。此时可以理解刚开始举的例子“小王到银行去开户，向大厅经历询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。”在这个场景中，小王是参与者，而经理和柜台职员及其他事物都在系统边界以内，属于业务工人。

用例在UML建模中是最最重要的一个元素，用例是一种把现实世界的需求捕获下来的方法，一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结界的一系列活动的集合。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。是相对独立的，用例的执行结果对参与者来说是可观测的和有意义的，这件事必须由一个参与者发起的。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例必然是以动宾短语形式出现的。一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。

边界在UML图符里的定义只是一个简单的矩形框，矩形的四个边决定了边界的内外。自顶向下的方式：通过逐步缩小边界进而影响到我们可以观察到的事物，也就决定了我们的抽象层次，似的我们的分析粒度可以有条不紊的逐步细化。当然我们也可以采取自底向上的方式，先把边界设定到较小的范围，比如从发动机开始讲起，扩大到传动系统，在扩大到整车性能。灵活使用边界。

业务实体描述了我们使用什么来达到业务目标以及通过什么来记录这个业务目标。方法是访问一个业务实体的句柄，它规定了外部可以怎样使用它。首先建立业务用例场景；然后从业务用例场景中逐个分析动词后面的名词，他们就是业务实体的备选对象；最后分析这些业务实体之间的关系。

对于软件来说，最主要的一个风险就是需求变更或者需求理解错误。一个有效的应对方法是尽早验证，并控制风险的影响规模。这就是说，假如需求变更风险无法避免，就让变更发生在项目的早期并且与之相关的部分还没还有大规模开发之前。尽早给客户提供一个可运行的系统，让他们看到并使用系统后说出不合适的地方。通过迭代方式，技术风险和人力资源风险也能够降低。

边界要划分清楚，不然系统就会无限制的扩张，以至于到最后加入太多复杂的功能，先列清边界外与他交互的人和物，定义组建要用在其需要的地方，组建是可复用的单元，哪怕只有一个，；理论上来说都可以在其支持架构内独立部署，并且可以被多个其他程序使用。编写程序时也是，将一个功能单独拉出来写成传入参数的函数封装，以便于出错时可以无不连累，单独拿出来函数还可以用于其他软件开发。