UML Training Notes

I got UML Training by UMLChina these two days, here now I just want to note it down before I totally throw them behind my head weeks later.

First I want to say, I started to know UML is about 5 years before, and I believe that UML is a great tool. However, till now, after the training, I am still believe that, "I can do project without UML, I can do nothing with UML". But I am trying to conquer it, and take its advantage into my daily job, cause I am now, doing business requirement capture and analysis, then make some design and deliver the function to build team. I just want to use UML to perform professional, and make communication among people more effective. 

Now come to the topic.

场景1：一个大神向team讲一个需求或者功能，他 只花了10秒画了一个high level的图形，然后花了半小时讲这个图形背后的含义。把简单的东西解释的详细和复杂，确实是大神。但是他不是在做PPT讲解，不需要内容如此精简。他要做的是讲需求或者功能完整的表达给team，能有严密的逻辑图形的记录。面对一张最简单的图形，大神拥有的无限的解释权，当team理解错误时，大神可以说“你理解的不对，这个要这样解释，让我解释给你听，...” 日常开发中，不需要这样的隐晦的，只有你脑袋里懂的东西，需要的一份没有机会发生错误理解的文档。一份完备没有歧义的文档，可以迫使自己去思考更多的东西，发现自己思考中的弱点。

场景2：一个外包团队去给某公司开发系统，来改善公司某业务的流程，提高效率，降低成本。和客户沟通过后，需求人员容易凭影像和自己的理解，拍脑袋的方式去裁定业务需求和系统功能。拍脑袋，其实也是信息在脑子里转，经过初步的整理，得出来的结论。但是这样的过程不严禁，结论不准确，因此系统做出来就可能不能切中要点，不满足客户利益。UML工具，可以帮助捕获业务信息，推到系统需求，做到严谨，戳到痛点。

以下讲说道的，只是UML工具箱中的几个工具：用例图（业务用例，系统用例），时序图，类图。就使用这三种工具，来完成业务建模到系统设计。

大步骤：

愿景 －业务建模 － 需求 － 分析 － 设计 － 实现

愿景

从目标客户责任人出发，对系统设定的可度量的指标和好处。比如：银行开户部门的老板希望新的系统能讲开户时间从平均30分钟降低到10分钟。对系统的大目标具有指导性，并且是可度量的。

业务建模

确定研究对象（边界），找出业务执行者（business actor），业务工人（business worker），业务实体（business entity）。这个阶段的输出是业务用例图和业务时序图。用它们在下一阶段来推到需求。

研究对象这里一般为一个组织或者一组人群。例如考虑做银行系统，研究对象为银行；医院系统研究对象为医院这个组织。

组织外的人或者系统为业务执行者，与组织发生交互；

组织内的人为业务工人，在组织内协助完成业务。如医院系统中的医生，保安；

组织内的系统为业务实体，在组织内协助完成业务。如医院某个已有的系统或者工具。

业务工人和业务实体都被看作组织内完成业务的组建，他们可以是人可以是工具可以是系统，重点是他们可以被替换。我们要做的新系统就是要去实现某些功能，去替换现有的那些组建。这些被替换的组建所负责的功能，就可能是新系统的需求。

业务用例：是从组织的外观的角度去看，它是体现组织为业务执行者提供的本质价值。业务用例是持久的，有没有计算机系统就应该存在。例如：医院作为组织，本质价值是看病，而不是挂号；保险公司作为组织，本质价值是投保，而不是登录系统。

业务用例的参与者可以是业务执行者，业务工人和实体。

业务时序图：是从组织内部的角度去看，分析业务的流程，用来改善业务流程。时序图的主角就是上面分析出来的执行者，工人和实体，还可能会有时间这个特殊的实行者。

从时序图上去分析当前业务流程中不足的地方，去用新系统改善业务。

计算机系统改善业务的方向：

1. 物流变信息流（最容易，最常见的方式）

2. 优化信息流

3. 封装领域逻辑（核心，最难最有价值的地方）

当新的系统作为一个组建放置到组织中时，就应该达到以上改善的一点或者多点，这才是做新系统的意义。（当然这个意义是受“愿景”指引的）

需求

找到系统能帮组织做哪些改善时，就是推到出了系统的需求。表达系统需求，要使用系统用例图，和用例规约。

画系统用例图时，要注意，与业务建模不同的是，这时的研究对象从组织变成了系统。因此系统用例的执行者是，系统外与系统发生直接交互的人或者其他系统（时间也是）。有主执行者和辅执行者之分。一个用例不能没有主执行者。

系统用例体现的是系统的核心价值，没有粒度之分。所有的核心价值都可以体现在这里。所谓核心价值即卖点。保险公司网站的卖点是“哇，这个网站可以投保～”，而不是“哇，这个网站可以登录输入密码～”。取款机应该是“哇，这个机器可以取钱～”，“哇，这个机器可以查询～“，而不是”哇，这个机器可以插卡～“”哇，这个机器可以输密码～“。输密码只是一种认证手段，而认证手段可以在专门的认证系统中作为用例，”哇，这个系统能刷卡认证“”能指纹认证“”能输密码认证“。

步骤不是核心用例，当多个用例有相同的步骤时，可以将此步骤抽出来，变成可重用的用例，来给其他用例调用，而不能直接给参与者调用；

CRUD操作不是用例。