大象Thinking In UML培训_王磊总结

加这次培训，受益匪浅。
一、对UML从知道到理解
UML不只是一个工具，是一个方法，他贯穿了需求分析、架构设计、详细设计、编码实现、测试。。。，必须从源头就把握住，每个环节注意才能做出最符合用户需求的软件。
UML不止是一个方法，也是一个观念，他要求一切从客户价值（使用场景）出发，这与敏捷、IPD其实都是一致的。
UML不止是个观念，也是一套体系，敏捷强调价值交付，其他UML也是，他把软件开发分成几段，每一段是独立的，都有自己的职责和价值，每一段也是关联的，前一段做好后一段才能有效的实现。
二、用例驱动开发
之前我们提BDD、TDD，说来说去也都是这个意思，软件面向用户，最能让用户满意的软件就是最符合他使用习惯为他提高最常用操作效率的软件，所以用例是头。
需求分析应该不止是需求的收集，应该有用例的分析。
测试用例的设计其实也应该往前一步，从用户的场景开始着手设计。场景抓住了才能设计有效的覆盖率更高的测试用例。
三、分工明确才能高效
老师每个环节都提到边界，分析的过程是有边界的，这就提醒我们再哪个步骤就只考虑这个步骤的事情，边界一旦没有建立起来就容易在分析阶段陷入细节，分析业务时你已经开始考虑计算机的实现，考虑某个特殊处理，
过程一旦混乱，原本很简单的工具也可能变得很复杂，在分析的过程中就能面向对象，时刻定义好边界，复杂的软件也会更有章可循。
分析、设计，每个阶段都有自己该干的事情，如同老师讲到设计过程中控制类的恰当抽取和划分让每个类各司其责，这样才能让我们更好的适应需求变更。
四、控制类
这个单提出来是因为在听课的过程中联想到较多目前的自动化框架，以前总犹豫哪些该抽提、哪些不该抽提，改一下子全改还是将就算了，这次有的新的想法，还是基于用例，是否要抽提看看有没有这种需求，优化、改造可以从现在开始改，从以后的代码或者你用到的开始改，允许旧的代码和新的代码共存直至旧的全被替换掉。
五、有效的测试
以往提到类似的培训，就开始觉得人家那样的测试真好，覆盖率真高，哎。。。
这次不一样，老师的培训让我感受到什么都是从不好走向好的，我们做不到，也可能我们不需要，还是回归本质我们的用例是什么？我们需要什么样的覆盖？再推导什么才是有效的测试。

Labels parameters