tianx.net 2004-12-30
几年前看过高展的“全程建模”，颇有收益，应用于项目中的业务建模，能够解决一些问题，通过实践，也深感业务建模很重要（当时在做企业管理软件）。采用“全程建模”提供的方法和工具（实际上是IDEF）进行业务建模，非专业人士稍加解释也看得懂。
后来看UML、RUP，实践中觉得其中的一些方法、工具又是一种不错的业务建模方式，经过一两次“培训”（就是拿着写好的文档讲给他们听而已），非专业人士也看得懂。
再后来看XP，结合实践觉得“经过裁减的RUP等‘重型方法’+XP的某些原则”，也是很不错的，不过XP就没什么业务建模的概念了。
我是个“投机派”，呵呵，实践中觉得有用就拿来用！
lingice 2005-01-04
对这篇文章很有感触！
最近的一个项目就遇到了“业务”问题，我们这个项目“发起者”和“最终用户”是分开的，而且完全不在一个部门（领域），我们开发小组成员对于这个“领域”也是完全陌生的，项目催的比较急，领导们整天说“赶紧把总体方案”拿出来，可是我们这个Team对这个领域太陌生了，而用户方很忙（他们确实很忙，而不是有意阻碍），关于业务这方面交流有限，更谈不上“对业务流程建模”了，我们想跟着用户，在他们的日常工作中探索业务，可是由于种种不可抗拒的因素，如密级很高，而无法实施！
针对于这种项目如何实施“业务建模”？！而且用户对于自己业务流程的把握也不是很到位，举一个极端的例子，如：作战时物资的调配与供给，没在这种环境下就很难把握住“正确的流程”，更何况战场错综复杂，何种是正确、何种是错误很难说得清楚！
不知道我举的这个例子恰当不恰当？！总之，业务建模是非常好的，但在一些情况下是很难实现、很难把握的！
不知道有没有朋友遇到过和我类似的情况！
o6z的评论:
典型的瀑布思维方式。
业务建模及其产生的业务模型非常可能是在你还没有接触客户而只是接触了领域的时候就产生了的，这一点非常的好理解。而对于从业务模型上推倒出的实现领域模型，也非常的可能在需求分析之前就已经产生的。而且这些模型越是早的产生，就说明这个组织对于领域和业务的积累深厚。到真正面向实施的时候，由于已经存在一个系统化的业务和开发框架，实施起来就会轻松的多。
这篇文章我很早就想作一个点评，但是当时我没有时间。现在好了，我来作一个我自己的阐述。
引用
了解目标组织（将要在其中部署系统的组织）的结构及机制。了解目标组织中当前存在的问题并确定改进的可能性。确保客户、最终用户和开发人员就目标组织达成共识。导出支持目标组织所需的系统需求。 （来自RUPCN）
这段话有问题。这个目标是没有必要达成共识的。而是要理解不同的涉众各自不同的目标，而这些目标很多时候是相互矛盾的（比如卖方和买方的矛盾，管理者和被管理者的矛盾，业务方和竞争对手的矛盾）。实际我我们操作的时候需要的是找到最应该满足的那部分涉众的目标，并且在一定程度上去满足这些目标的非对抗目标。但是实际上这个问题还需要特别的考虑。如果你是在项目前对于领域进来了解的时候进行这个业务建模（我更愿意叫做领域建模），这个时候得到的模型应该非常明确的反映出这个对抗的关系，以便于在具体针对项目的时候进行有目的的权衡。
而由于作者在最初的基本出发点上就存在这样的未深刻理解，所以在后面的论述中存在非常多的微妙的错误，而且造成的影响很多是本质上的问题。
引用
以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。
为这里作者实际上阐述的有些不清楚，很多情况下业务主角并不是顾客，比如你要建立的模型是为财务管理服务的。
实际上这里隐含一个作者的想法，这一点大概也是RUP的一个问题。那就是过早的划分出了一个模型所要针对的需求对象。而在我这里，业务建模如果是在项目的前的领域分析的时候，特别是在建立分析模型的时候，关键的是在描绘场景，而非过程，或者是业务领域中有些什么对象（概念模型），而不是有些什么过程（业务流程）。这是由于业务流程会随着业务的实施具体环境的不同有所不同，过早的具体化会造成后期对于真实用户业务过程理解的污染。但是我们也清楚实际上这个业务过程是非常重要的一个业务领域中的概念，如果不在早期就有所准备，那么后期的工作也会非常困难。解决这个问题的方式就是尽早的建立业务规则库，这个问题我会在今后作专门的阐述。
引用
但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？
一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。
那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。
明显的作者这两段话之间是有矛盾的——前面一段是隐含者说业务建模是需求建模的一个部分，后面则又在说业务建模可以在项目前就产生。是什么原因造成作者的这个矛盾呢？
根本原因还是在于作者没有跳出瀑布思想的束缚，依然将对于业务和领域的工程化分析强行的加入需求工程中来。我们知道需求是客户的真实需要，而没有客户也自然不会有需求，当然没有项目自然就不存在客户。当然有些产品的开发虽然没有确定的真实客户，可是还是存在着假想的目标客户。而我这里所说的，恰恰是在业务建模的有些时候，特别是项目前的最初阶段，你不应该确定 你需要满足的个别人群，而是要阐述在业务场景中所有涉及到的群体。
文章来源于领测软件测试网 https://www.ltesting.net/
