UMLChina首席专家   潘加宇

利润＝需求－设计

利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：第一，要卖出好价钱；第二，制造的成本要低。妙就妙在，价格和成本之间没有固定的计算公式，这就是创新的动力之源。放到软件业上，笔者也炮制了一个公式：利润＝需求－设计。

需求工作致力于解决“产品好卖”的问题，设计工作致力于解决“降低成本”的问题。二者不能相互取代。你能低成本生产某种软件产品，但不一定能保证它好卖。你的某种产品好卖，但如果生产成本太高，或者在市场需要新型号时，无法复用之前的组件，又要投入大量人力物力去制造轮子，最终还是赚不了多少钱。要迈向“低成本制造好卖的各款产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践下面四项技能。

业务建模。描述组织内部各系统(人肉系统、机械系统、电脑系统等)如何协作来为组织的“客户”提供服务。新系统只不过是组织为更好地满足客户，对自己的内部重新设计而购买的一个零件(和招聘一个新员工没有本质区别)。如果能学会通过业务建模去推导新系统的需求，而不是拍脑袋得出需求，假的“需求变更”会大大减少。

需求定义。聚焦于待开发系统的边界，详细描述系统要卖得出去必须具有的外部表现——功能和性能。这项技能的意义在于强迫我们从“卖”的角度思考哪些是涉众在意的、不能改变的契约，哪些不是，严防“做”污染“卖”。需求定义的结果——需求规格说明书是“卖”和“做”的衔接点。

分析。提炼系统内需要封装的核心领域机制。可运行的系统需要封装各个领域的知识，其中只有一个领域(核心域)的知识是系统能在市场上生存的理由。对核心领域作研究，可以帮助我们获得基于核心域的复用。

设计。将核心域知识和非核心域知识结合，最终实现系统。“代码就是设计”指的就是这狭义的“设计”。代码确实是设计，但代码不是分析，不是需求，不是业务建模。

我观察到，以上四项技能，开发团队做得较好的是设计，前面三项都相当差，特别是业务建模和分析，没有得到足够重视。很多开发团队拍脑袋编造需求，然后直扑代码，却不知“功夫在诗外”。更糟糕的是，一些开发团队以“敏捷”为名，干脆放弃了这些技能的修炼。就像一名医生，因为缺少检查、诊断、拟治疗方案等技能，索性说：唉，反正再高明的大夫，也不能一个疗程把病人治好，干脆我也别花那么多心思了，随便开个药给病人吃看看吧，不好再来！其实，掌握技能才能真敏捷。

UML

注意，上面我只是提到了建模，没有提UML。也就是说，只要你思考过、表达过上面这些问题，就是在建模，用文本或用自造的符号都可以。当然，使用UML是目前一个不坏的选择。

UML是当前软件建模的一种语言标准，不止是OMG的标准，也是ISO的标准。随便打开一本在版的软件开发书，如果提到建模，使用的符号基本都是UML，即使随便画个草图，也是UML的样子。这种统一的符号体系，在数学、音乐、建筑、电子等许多行业和学科都有。建模符号的统一，也导致了建模工具市场的繁荣，以UML为基础的建模工具目前已经有100多种(http://www.umlchina.com/Tools/Newindex1.htm)。

就像五线谱不只是一套标准符号，背后还隐藏着基本的乐理一样，UML的背后也隐藏着对建模的一些基本共识。很多开发人员并不喜欢UML，更喜欢画一些自己的草图，因为这种做法有一个开发人员特别喜欢的优点，怎么画好像都对！问题就在于，怎么画都对的东西，不能强迫开发人员作严肃的思考。相对于功能、特性、模块等这些模棱两可的说法，用例、类、状态等概念要严肃得多。

严肃的思考，这就是业余和职业的区别。面对一个棋局，下一步怎么走？在业余棋手看来到处都是正确答案，在职业棋手眼里，答案只有两三种。

表1列出了推荐的UML用法。下面我回应一些比较典型的针对UML(其实是针对建模)的疑问。

[/caption]

做小项目还要建模吗？

我首先要问，你做的“小项目”真的是小项目吗？如果说“小项目”指的是很容易达到要求的项目，这样的项目往往赚不了多少钱，因为在运转良好的市场，竞争者很快就会进入，利润立即降到低水平。你的“小项目”，一旦置身于市场竞争之下，就会发现软件的复杂度很快膨胀到只有少数人能应付的水平。市场就像一份奇妙的考卷，大家都会，考卷是废的；大家都不会，考卷也是废的。好的考卷，得高分的总是少数人，您要想办法成为这少数人，就需要极其精良的需求和设计技能。

我在后面的文章里还会不断提到学生思维和市场思维的区别。像完成老师布置的作业一样，做一个iPhone软件不难，做一个好卖的iPhone软件在市场上杀出血路，难！敏捷宣言说“可以工作的软件”，远远不够，我们要的是“可以卖的软件”！

可能有人说：噢，利润低没关系，我可以做很多个。如果是这样，问题就变成了：如何用尽可能少的组件灵活组装出长得差不多但不完全相同的“小项目”——已经是大项目了！

不同形态的系统有各自的复杂性，看起来做一个“电厂管理信息系统”好像很牛，但做一块电表的学问也不小。1999年，我创建了UMLChina，专心研究软件的需求和设计技能，为软件组织提供(而且只提供)需求和设计技能服务。到现在为止，已经上门为超过130家的组织提供服务，覆盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制等领域。业务建模、需求、分析等建模技能都适用于这些企业的项目。也就是说，无论是上百万人同时使用的社交系统、行政人员使用的内部办公系统，还是埋藏在人体内的小设备，建模是否值得，和系统的运行形态无关，而是看软件组织有没有一颗冠军的心。

[/caption]

许多著名的开源项目为什么没有用UML建模？

流行起来的开源项目，核心领域多为基础设施领域。基础设施领域的“负载”(需要依赖的领域的数量)较低，只需关注计算机的资源，不需关注医院、税务、物流等。因为负载低，基础设施级别的分解和复用相对容易。现在做一个简单的应用，也许只需要在窗体上摆几个文本框、列表框、按钮之类，双击，添加“一点点”业务代码，一个可以运行的应用就产生了。这其中的绝大多数工作，微软等公司已经做了(相关的利润也被赚走了)。另外，基础设施领域有大量的教材和先行例子，程序员在学校里已经受过这方面的教育，大脑比较容易把握基础设施领域问题的复杂性，所以对建模的要求没有那么高。

很多能够带来利润的系统“负载”比较高，除了核心领域(如医院)的知识，还要依赖于其他非核心域的知识，而且，核心域并没有那么多人去研究。很少有类似这样的书，把一家医院的流程、各种业务对象之间的关系，用某种方法(彩色UML建模也好，以前的数据流图＋ER图也好)研究得透透的。要在市场上获得竞争优势，有必要把复用的级别提升到核心域的复用(因为其他的好处，竞争对手也能获得)，这确实很难，但再难也要做。这时，建模技能就必不可少了。

我每年都会参加一些开发大会，常看到类似这样的场景：某电子商务网站的架构师上台讲了一通，接着某视频网站的架构师上台也讲了一通，咦，两个演讲内容如此相似？原来，他们讲的都是自己系统中非核心域的知识，我们的架构师对核心域的关注还是太少。

我将在以后的文章中，继续回应针对UML和建模的问题。

(感谢电子工业出版社博文视点武汉分部负责人周筠对本专题的贡献。)

金山软件刘鑫：有限使用UML

盛大创新院霍炬：UML——一种体系和一种思想

(本文来自《程序员》杂志10年08期，更多精彩内容敬请关注08期杂志)

《程序员》8月刊最新上市：http://www.programmer.com.cn/3742/

《程序员》订阅：http://book.csdn.net/programmer/