OJT 2019-7-29 22:39
请教一下各位business entity的定义和用途
UMLChina潘加宇:
OJT
嗯，这是《软件方法》的定义。不同的方法Business Entity的定义多少有些差异。例如
RUP：A business entity is a class that is passive; that is, it does not initiate interactions on its own. A business entity object may participate in many different business use-case realizations and usually outlives any single interaction. In business modeling, business entities represent objects that business workers access, inspect, manipulate, produce, and so on. Business entity objects provide the basis for sharing among business workers participating in different business use-case realizations.，
EA用户手册：Passive class accessed and manipulated by workers.
《软件方法》的定义更具体，跟大家探讨下对建模过程和产物的影响。
UMLChina潘加宇:
先说一下历史。
UML标准里没有"Business Worker"和"Business Entity"的概念，建模时表达为类的构造型。
这两个概念来源于Ivar Jacobson的方法学。
在"The Object Advantage"（1995）和"Software Reuse"（1997）中，Ivar Jacobson将面向对象思想用于描述业务流程，把业务流程看作是一系列业务对象之间为了完成业务用例而进行的协作。
图1 摘自Jacobson I., Ericsson M., Jacobson A., The Object Advantage: Business Process Reengineering With Object Technology. ACM Press (1994)
图2 摘自Jacobson I., Griss M., Jonsson P., Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley (1997)
在RUP（Rational Unified Process）的文字里，正式出现"Business Worker"和"Business Entity"的说法，并作为类的构造型在Rational Rose等工具中使用。Rose里的图标和RUP里的图标有一定差距，反倒是EA里的图标和RUP里的更相像。
图3 摘自Kruchten P., The Rational Unified Process: An Introduction (2nd Edition). Addison Wesley (2000)
图4 Rational Rose里的业务工人和业务实体
图5 EA里面的业务工人和业务实体
说完了历史，接下来评价一下上面的定义。
关于业务工人，歧义不大，组织里的人肉零件。
关于业务实体，Ivar的书或者RUP里的知识是考虑不周的。主要问题是：把"业务实体"混淆为用面向对象方法构思软件系统时的"实体类"，然后把它和业务工人并列，导致抽象级别不一致。像图1中，把Loan Application和Account并列?是不合适的。?
组织的业务用例由组织内的各个系统协作实现。
例如，以某家企业为研究对象：
员工是业务工人。注意，这个员工是父母老师培育的人肉智能系统，和有没有软件系统、软件系统是不是用面向对象的方法来构思没有关系，时光倒流300年，这个人肉系统也存在。很多人在这里犯糊涂，把外面的人肉系统等同于软件系统用面向对象方法构思时（如果不用面向对象方法构思就什么对象也没有）的一个"员工"对象。
财务系统、钉钉系统甚至计算器可以算是业务实体。这些系统也是智能系统，和业务工人并列没问题。
但是，把订单（不管是一份纸质订单还是软件系统里的一个"订单"对象）当成业务实体，然后和业务工人并列，是不合适的。员工和其他员工协作、员工和软件系统协作可以，员工和一张纸协作、员工和某个软件系统里的一个"员工"对象协作说不通。
实际上，员工就算和软件系统的某个对象交互，那也是一个边界类（例如"员工界面"）的对象?。?
有的人可能在这里又会犯糊涂："订单"有智能啊，"订单"类的状态机封装了很多逻辑在里面呢。如果是这样，把前面文字再看一看。
《软件方法》中，把业务实体定义为"非人智能系统"。如果需要在业务序列图中表达A请求B做某事，传递的参数是一份订单，那么可以加一个类"订单"，但不加业务实体构造型。
如果硬要把订单称为业务实体，也不是不可以，那需要找另一个词来表达"非人智能系统"，不要把它和没有智能的一张纸或者它内部的一个对象并列。
最后要说的是，要用发展的眼光看问题，不能搞"原教旨主义"。
某种思想或方法起源于某人，不意味着某人最初对该思想或方法的认识永远是最正确的，也不意味着某人在以后的岁月中针对该思想或方法发表的各种观点都是正确的。
我从2005年开始，使用Ivar Jacobson的方法学做业务建模，也指导很多团队做了大量的业务建模工作，也写了很多文章。之所以写"从2005年开始"，是因为在这之前业务建模的业务流程部分我用的是活动图。
通过大量的实践不断调整和加深对业务建模的认识，我认为许多先行者没有考虑过或者考虑不周到的问题，我已经考虑过了。
《软件方法》中的内容及其衍生物是先行者没有过的积累，是目前认识最到位的高效从业务建模推导出系统需求的方法。有怀疑的读者，可以去看书或者UMLChina网站、公众号的内容。
这和当前的某些“创新”是不一样的。有一些人，不学习不思考，在对前人积累不了解的情况下，凭着自己的一些朦胧认识，随便抛出新概念忽悠他人，认真一看，那些认识连前人的尾巴都碰不到。这样的人，国内国外都有。
