统一过程建模的总体思路

    拜读了谭云杰老师的《thinking in UML 大象》，很厚的一本书，主要对通过UML语言对统一过程设计的设计过程做了详细的说明讲解，本质上这本书是一本工具书，通过对UML的核心元素、核心模型、核心视图的详细介绍以及谭老师实践中的一个项目样例系统的讲解，对UML在统一过程的应用作了系统讲解。

    其实这里说是讲解，更多的是深度分析，并非只是讲解基本概念，而是更多的讨论，更多的将在实际应用中的应用价值以及如何使用进行了说明。虽说总体上通俗易懂，但是要啃完这样一本大部头的干货，很难。不过，谭老师也说过要根据实际情况来进行裁剪，UML统一过程理论是一套理论和标准，就像CMMI一样，有指导性的价值，可是不能照搬，没有谁见过哪个公司完全照搬CMMI标准执行的，估计有应该已经gg了。

    说下自己的理解，已经很久没有听说过有哪个公司使用统一过程进行项目设计和研发了，充斥耳边的都是敏捷、scrum等等，貌似非常高端的内含“快”这样的暗示性词汇的方法论。但我想说的是，统一过程（RUP）跟敏捷应该就不是一回事，从我认识的做敏捷教练的朋友对敏捷的描述（本人没有学习过敏捷，如果理解有肤浅，敬请原谅，后续如果有机会还是要系统的学习下），敏捷更多的是一种管理过程的指导思想+工具的，本质上更偏向管理；统一过程是一种技术项（广义的技术，并非指的coding，应该更多的是设计技术），应该说与敏捷并不冲突。像谭老师在书中所说，在不同的项目场景下会应用不同的策略，例如在把当下的互联网型项目比作一个泥塑，把业务逻辑复杂的大型To B商业项目（如ERP、业务系统）比作火箭，一个泥塑可以快速的拿过来捏成想象中的模样，如果哪里不合适可以快速的修正或者重塑，这正是敏捷；如果是要造一个火箭，快速的早出来再重塑？几乎是毁灭性的，但是如果是火箭上的一个螺丝钉倒是可以考虑敏捷尝试。

    统一过程通过比较严谨的思路和工具将现实世界到计算机程序的转化过程具像化为可视可理解的模型，并通过定义的一套语言（UML）对其过程进行描述，我们在实际使用过程中，高层的理解应该是保证现实世界到抽象计算机世界的转化过程中的完整性和一致性，即不能失真（这个应该是软件行业最严重的问题了，通常听到的撕逼的“变更”大部分应该指的这部分）；低层次的理解应该就是使用哪些工具来保证这个转化过程，比如他的核心模型、核心视图。

    另外想说的是对于一个像笔者当下正在进行的公司内部产品的研发过程，笔者认为也非常适合使用这种“传统”的设计思想和工具，更加严谨更加利于抽象过程，更加利于商业项目的产品化过程，虽然对大部分的投资人来说，这个太“慢”了，我想说，做B端产品（注意，这里不是项目）想快，现实吗？面对那么多繁杂的业务场景，业务逻辑，理解过程就是一个非常复杂的过程，你用一个月的时间理解人家几十年的行业业务，已经是一种奇迹了。从某种意义来说统一过程提供了一种方法一种理念来帮助我们快速的理解行业，快速的变成行业的专家。