《程序员》杂志第七期有篇潘加宇的文章《业务建模VS系统建模》。最近正好一直在做业务建模和系统建模的工作，所以对这篇文章中的很多观点体会颇深。
?
1、“业务建模并不意味着有软件项目开发跟随”。
记得一年前，公司一个会我发言，为了说明扎扎实实调研分析透客户单位的实际业务对后期系统需求分析的重要以及要避免过早去考虑软件系统需求甚至设计的时候，我说“我们就假设我们调研不是要开发软件，就是要弄清楚实际业务，建立业务模型以优化业务管理”。我想只有这样我们才能抑制住自己的浮躁，技术人员往往让过早的系统分析和设计来掩盖其对业务的稀里糊涂。他们往往在没搞清楚实际业务时就臆想以后的系统，而在真正分析设计系统时又去臆想客户的实际业务，当然这种分析设计是建在沙丘上的建筑。所以当我们抱怨客户的需求总是在变的时候，我们是不是也要反思一下，他们的业务多少年来从不变化，是不是我们根本没有真正理解业务，自然也不能很好的捕获到客户真正的需求，更不要说给客户有价值的需求建议。
?
2、“业务建模有助于描述‘战场’的真实态势，帮助你从中寻找软件的切入点”
最近对项目一个子系统的改造就是采取先建立业务模型而后编写系统用例进入需求分析设计的过程。在编写系统用例时，一碰到较为复杂混乱的情况，系统用例事件流无法进行的时候，我总是去再仔细阅读业务模型，尤其是其中的业务用例，在实实在在的实际业务基础上去梳理系统究竟要做的事情，系统究竟怎么做更适合客户当前的业务模式，怎样才能让客户感到使用我们的系统给他们带来了方便，带来了益处而不是麻烦（当然这要有个度，因为客户给的钱有限）。这样编写的系统用例在辅助以系统原型，应该可以更逼近于客户的需求。而这个系统以前的设计明显是对实际业务一知半解的，因为在业务中最复杂的情况也恰恰是原来的系统设计无法处理或设计不合理不对的地方。
?
3、“业务模型的结果能自动映射到软件需求吗？”
这显然是不可能的。业务模型中的核心——业务用例，描述的是实际业务的场景。而需求模型中的核心——系统用例，描述的是未来的软件用户与未来交付使用的系统软件的交互场景。也许一个业务用例在系统中会有多个系统用例去覆盖这项工作价值。也许一个系统用例可以实现多个业务用例才能实现的目标。另外，系统对象模型中的对象也未必就是业务实体模型中的一个实体，它们也无法一一对应。说明以上的最好证据是，如果业务模型的结果可以自动映射到软件需求，那我也不会今天阅读着业务模型编写系统用例时而还要思考得头痛。虽说它们都主要使用用例技术，可这毕竟是两码事。
