在学习UML建模语言的过程中，你可能会遇到UML业务建模问题，UML业务建模的产出工件，最实用的是--业务词汇表、业务用例模型和业务分析模型。请看本节详细介绍。
初缠之UML业务建模
业务建模是整个RUP四段式还没开始前一个可选的序章：
1.开发团队对目标组织的业务非常白痴，没法开展系统用例需求。
2.寻求业务流程改造(BPR)和自动化。
这两个可能的原因，层次上相差甚远，但目标都是端平客户与开发团队的视线。对于小团队，可以只对--与待开发软件系统相关的，最不清晰，最重要的一小部分业务进行建模。
RUP很聪明的把用例建模的很多概念和流程复用到了业务建模中。IBMDW中文站有一个很好的教程《理解需要解决的问题:业务建模技术简介》（需免费注册DW帐号)，看完就差不多了，业务建模已超出了软件范畴，RUP的细节描述和那本《UML业务建模》都未必绝对正确，所以RUP文档里的种种细节都不必深究细看。
简单说来，UML业务建模的产出工件，最实用的是--业务词汇表、业务用例模型和业务分析模型。
业务用例和系统用例是同胞兄弟，只不过后者的主角是待开发的软件系统及其提供的功能，而前者的主角转向了整个目标组织，及其核心业务和支撑、管理的业务，而且通常组织里不止你一个系统。
分析模型表达了组织内部如何的实现业务用例。为了照顾阅读者的水平，使用比较直观易懂的泳道活动图而不是分析模型常用的顺序图来表达。我通常在用例底下直接添加活动图，而不是新建一个UseCaseRealize。
这两个图里一般有四种图元：
◆BussinessUseCase，业务用例。
◆BussinessActor，目标组织外的客户或合作伙伴，系统。
◆BussinessWorker，目标组织内的员工和系统。
◆BussinessEntity，业务实体，适合那些对数据对象盯得很紧的信息系统。
可以很简单的从业务分析模型转换出系统用例模型来。业务用例中待开发系统参与的活动就是用例，活动前后的BussienessActor或Worker就是Actor。
【编辑推荐】
