本节和大家学习一下UML业务建模方面的内容那个，UML业务建模的过程帮助我们理解了问题域的业务，同时，也可以启发我们寻找改进点，这些改进点往往形成了以后软件系统的需求。
UML应用实作细节——UML业务建模
在实施UML业务建模之前，我们首先应该问自己两个问题:
1."软件开发是否一定要做UML业务建模?"
2."业务模型是否可以直接映射到系统模型?"
答案都是否定的：业务建模不一定是必须的，很多软件项目面临的问题域（业务）可能很简单，就不需要UML业务建模，这也是总则中把UML业务建模定为软件开发第0步的原因；即是做了业务建模，由于它所表达的只是问题域当前是什么样，而不是使用软件系统时会怎样，因此，也不能把业务模型，直接映射到系统模型。
那么业务建模有什么用?答案是它可以帮助我们了解现状,启发愿景和需求,是进行精确有效的分析与设计的参考
实施UML业务建模的步骤可以分为:
1.确定研究范围：这里是指我们要观察的问题域范围，譬如一个要实施OA系统的企业，我们需要研究的范围可能包括整个企业的各个部门，也可能只包括相关的几个部门，这取决于我们将来要在多大范围内为系统服务（软件系统影响到多大范围）；这一步是基本前提，如果范围不明确，会导致以后的分析缺乏依据，或者产生矛盾；当然，以后的分析中如果发现问题，这个范围也是可以调整的。
2.识别业务执行者：注意，执行者是在系统之外的，这里的系统，并不是指软件系统，而是将要使用我们软件的活生生的业务系统，譬如一家银行，一家汽车制造厂，一个政府部门等等；因此，这里的系统范围，往往要比我们以后要做的软件系统范围大，软件系统的actor，很可能只是业务系统内部的一个业务工人（businessworker），而真正的顾客，才是业务系统的执行者，如银行的储户，汽车零售店等等。
3.识别业务用例：用例应该对执行者（actor）提供完整的价值，因此要从执行者的角度去考虑用例。比如对于病人来说，医院可以提供“诊治”的用例，而”挂号“，”吃药“等等就不是用例——因为这些都不能满足患者的需要，即不能提供完整的价值；事实上，”挂号“很有可能是”诊治“用例中的一个步骤。
发现用例时不应忽略一些支持性事件，比如”企业内部人员的发展与维护“”安全性活动“等等，它们为一些特殊的actor（如领导、董事会、政府）提供了价值
4.识别业务对象：业务对象是系统内部的东西，又分为业务工人和业务实体，它们的区别仅在于是否是人。很多时候，他们是可以互相替代的，例如银行的营业员和自动取款机。业务用例是通过业务对象的交互实现的。
这里的步骤本身就是迭代的过程，比如在识别业务对象的时候，可能又启发了新的业务用例，对业务用例的描述也可以从简单的文本转化为体现业务对象职责的活动图（泳道）和序列图。
UML业务建模过程帮助我们理解了问题域的业务，同时，也可以启发我们寻找改进点，这些改进点往往形成了以后软件系统的需求：
1.信息流转
2.演绎复杂逻辑
3.记录实体信息
4.自动工作,时间驱动
这些改进点有一个共同的特点，就是都是计算机擅长而人不善于做的事
尽管业务模型不能直接映射到系统模型，但它们之间还是存在一些可能（注意：只是可能，不是必然）的映射关系，具体如下：
1.业务用例可能映射到一个子系统
2.业务用例的一个步骤可能映射到软件系统的一个用例
3.业务执行者可能成为系统执行者
4.业务工人可能成为系统执行者
5.业务实体可能成为系统实体
【编辑推荐】
