使用UML进行业务分析（一）——常用概念及相互关系介绍
做一个产品容易，但做一个好的产品非常难。对于一般的从互联网行业转行而来的产品经理和业务分析人员来说，敏捷开发是常用的方法。但在做企业管理系统等ToB产品时，涉及到非常复杂的业务场景。如果沿用原来那一套业务流程图、功能流程图、页面流程图、数据流程图，则总是会出现一些逻辑漏洞，或者说没有一条主线逻辑告诉你，业务是怎样一步一步的转化成功能和页面的，如何一步步转化成系统交互和类的。而UML或者统一过程就是这样一个工具，更多的是一种思维方式，清晰的告诉大家如何进行业务分析，如何自然而然的将业务转变成功能和页面而不出现遗漏。故结合我这几年学习的理论和实践经验，将一般的过程介绍给大家，一块讨论学习。由于完全半路出家，都是靠自己学习、领悟和实践，有偏差和错误的地方，请专家指出。
0.前言
0.1 优点和必要性
1、UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。
2、UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。
3、UML使硬件组件和软件组件之间将会有更大的透明度。便携性和综合效率将会增加。
1 对于开发团队的层面来说：有利于队员间在各个开发环节间确立沟通的标准，便于系统文档的制定
和项目的管理。
因为UML的简单、直观和标准性，在一个团队中用UML来交流比用文字说明的文档要好得多。
2 对与各个开发项目来说：可以通过UML共享开发经验和资源
3 uml只是面象对象分析、设计思想的体现，和具体的实现平台无关，用UML建模和设计的系统可以用JAVA或C#来
实现。
4 这点对我们最有用啦：可以做为系统分析设计过程使用的表示和体现工具。
5 对于公司的运营层面：UML已经是世界标准，使用UML方便公司的国际化。
好处：帮助开发团队以一种可视化的方式理解系统的功能需求。
1，UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。
2，UML建模能力比其它面向对象建模方法更强。它不仅适合于一般系统的开发，而且对并行、分布式系统的建模尤为适宜。
1. UML概念和元素
按照业务分析的顺序，逐一介绍分析过程中经常用到的概念。
业务目标
业务目标就是客户对要建设的系统的期望。业务目标清楚后，可以从业务目标角度去定义业务边界。如，1.1.根据销售订单，创建成品和半成品的生产订单—是一个客户期望的业务目标。
业务边界
明确了目标后，要确定业务边界。业务边界决定了参与者和用例。在定义业务边界过程中，需要从需求出发。但是在明确需求的时候，边界通常应该是确定的。两者之间存在矛盾。因此，边界确定是一个在需求调研过程中不断调整的活动。
举个例子来说，我们在做生产管理系统的时候，为了满足“1.1.根据销售订单，创建成品和半成品的生产订单”的业务目的，究竟是否要包含产品计划拆分成零部件计划呢？如果划分到生产管理系统中，则参与者就多了一个，该参与者作为主角就会带来计划拆分的用例，进而扩大了系统的边界。因此，在做前期规划时，需要先假设该场景在生产管理系统内。在调研过程中，发现客户已经上了ERP系统，实现了该场景，则我们会将计划拆分场景移出生产管理系统边界，缩小系统边界。
用例
一般分为业务用例、概念用例和系统用例。用例就是一件事情，要完成这件事，需要做的一系列活动；用例就是在确定了业务边界后，以业务主角的角度发现的所有功能性需求的汇总。
用例视图
业务用例视图包括业务主角和业务用例，它是业务的高层和概要视图，并作为其他建模要素的组织点存在。业务用例的颗粒度，实现某一个业务目标为一个业务用例；
用例场景
业务用例场景用来描述该业务用例在该业务的实际过程，说明业务主角是如何执行完成业务目标的。业务用例场景一般使用活动图或泳道图来表示。用活动图来描述业务用例场景，必须将参与者和业务工人作为活动图的泳道，将参与者和业务工人所完成的工作作为活动。依据实际业务流程中的执行顺序将这些活动连接起来，形成业务场景。
1. 在描述业务用例场景时不能带有“设计”的思想，必须是真实业务的体现。
2.不要绘制充满分支，巨大的活动图。
用例实现
将业务用例实现关系连接到业务用例，每个业务用例实现代表了业务用例目标的一种实现方式。
用例实现场景
业务用例实现场景针对每个业务用例实现，说明该实现方式的步骤，即如何实现的，重点在于清晰描述用户和计算机系统的交互和操作。与业务用例场景类似，但更为明确。我们可以用页面流程图替换。业务用例实现场景是制作系统原型的基础。
业务用例规约
业务用例规约针对每个业务用例编写，它要说明业务用例的使用者、目标、场景、相关业务规则和业务实体等。
业务规则
业务规则是客户执行业务必须遵守的法律法规、惯例、各种规定，也可能是客户的操作规范、约束机制。业务规则可能影响软件外观、内部功能甚至架构。我们用到的必有的规则为对象交互规则和对象内置规则。交互规则可以标注在页面里；对象内置规则在对象描述里。
业务对象模型
描述业务模型中关键的业务对象，以及他们是如何贡献于业务目标的。一般用例场景或用例实现场景采用动词+名词描述。业务对象就是名词里面筛选出来的，与系统实现有关的东西。对于跨多个领域的对象，在每个用例场景分析完成后，将每个场景的表达相同意思的对象合并，就可以构成一个复杂的对象。在进行系统设计时，开发人员会用来参考进行数据库和系统对象设计。
包图
包图组织业务用例。可以按业务模块分包，也可以按业务主角分包，还可以按照组织结构分包。分包策略取决于具体环境更注重哪方面。
-
活动图和泳道图一致
-
时序图，重在消息传递顺序，用于描述消息传递等逻辑
-
协作图，描述关系
-
领域 ，对于跨多个领域的对象，在每个用例场景完成后，进行组合汇总，形成业务对象
-
用语尽量和客户需求保持一致
-
交互规则，对象内部规则就是对象说明
-
非功能性需求:
2. 和系统设计的关联
分析模型
在完成业务用例的基础上，可以对复杂或核心的用例场景创建分析模型，考虑到软件架构，使用时序图进一步描述核心用例场景的底层逻辑。分析模型完成后，也就能出来页面原型了。
系统用例
系统用例是业务用例通过映射、抽象、合并、拆分和演绎等创造出来的。系统用例也和业务用例分析过程一致：从业务用例映射成系统用例，通过活动图和时序图描述用例场景。此时，就可以得到类图，其中的一些活动转变为某些类的内部方法，一些活动转化为接口。不同的类通过抽象形成数据库表。
对于业务人员来说，得到用例图描述用例，活动图或泳道图描述业务实现场景，对象模型描述对象属性和规则，分析模型描述页面功能和系统内部运转逻辑，并据此推断出页面上的功能交互规则和底层的对象交互规则，避免了功能丢失。
出来了分析模型，也就出来了页面，对象，业务规则和逻辑
下一篇以具体例子来介绍整个业务分析的流程和方法。