以下是来自腾讯的jeri的体会。欢迎您有空也分享您的体会，可以通过底部的二维码微信联系。

接触UMLChina是在部门推行用例规约编写，部门邀请潘老师讲课，很遗憾授课现场我没能去，只在UMLChina网站资料学习软件方法，并购买了相关资料，潘老师著《软件方法》一书(书名很霸气)，学习过程发现潘老师在UML建模的知识面很广且深入，书中内容来自各家理论，通过自己的理解形成一套方法论，书中介绍了4个工作流，业务建模，需求，分析 ,设计。前两个工作流在《软件方法》上部(已有出版)，后面两个工作流在《软件方法》下部，暂未出版，有不完整的电子版。

潘老师在UML领域坚持研究并布道20年，如果没有对这份事业的热爱是不可能做到的，强烈建议软件行业从业者看看此书。

在部门推行期间，我写过用例规约，里面有一个系统的概念，系统这个词用的比较广泛，在写用例规约时对系统的划分比较难统一，同事之间有较多的争执，按书上的定义，在划分系统上会表现为模糊不清，最后与潘老师讨论，从卖的角度去理解，才彻底理解书中意思。因为写用例规约这帮人，之前主要写代码，都是从做的角度去思考，没有从卖的角度去思考。

在我的工作中，用的比较多的是概要设计，详细设计这种研发方法，相信互联网很多公司也是这一套流程，有些可能还没有设计，直接上来数据库表设计，然后按照产品需求填逻辑，这种面向过程的开发，在项目初期没有大多的问题，但是对于大型项目，在需求不断增加时，业务越来越复杂，基于面向过程的编程在复用上越来越难，当并发请求快速上升时，因模块划分的不合理，系统只能重写（注意不是重构）。除了基础能力层能复用(如TCP网络库，框架)，业务能复用的代大少了。

《软件方法》中对领域模型的分析方法比《领域驱动设计》一书更容易理解，领域驱动设计把对象划分分成三类，Entity,Value object,Service, 比较抽象，也难于介定，《软件方法》从用例规约提取领域概念更直观，现实世界事物间复杂关联性确实带了建模的困难，对象间的稳定关系也可能随着业务的变化而调整，从分析模型到实现会有各种妥协，因不同的基础设施（编程框架）而有所调整，《领域驱动设计》作者也提出模型与实现最后不相符或难于维护的案例，我个人在这方面也是开始实践，对模型到实现会遇到的困难了解不深入，但是通过分析方法来深入了解系统里各对象的关联关系，并分配合理的职责是很有必要的，作为项目的资料的一部分，对接手项目的人也能快速了解系统。

最后感谢潘老师在部门用例规约编写过程中的热心指导，让我们从做的视觉切换到卖的视觉。