之前分享了几篇UML学习之前的几篇文章，关于UML核心元素、核心视图和模型。要用好UML需要明确知道自己的目的，知道自己想要做什么，根据自己的目的寻找合适的模型，确定模型之后，再确定采用哪些视图来表达模型。
如何知道自己想要做什么呢？可以在软件过程中寻找，软件过程明确了软件的生命周期，每个周期需要什么样的模型来表示。因此学习UML，必须结合软件过程，虽然任何一种软件过程都可以使用UML，但是统一过程仍然是对UML使用最为精深的，毕竟这两者师出同源。
下面将会讲下使用UML建模时统一过程在各个阶段要执行的主要工作。我们会精简的引用一些统一过程的核心工作流，主要阐述建模过程在统一过程中的位置以及主要输出和输入，让我们看看UML的各种视图和模型是如何运用在项目的各个阶段的。
我们将举例四个最常用的工作流:
业务建模工作流
系统建模工作流
分析设计工作流
实施建模工作流
一、业务建模工作流
业务建模位于统一过程的先启阶段，主要使用到的模型包括: 业务用例模型，概念用例模型和领域模型。
工作流程如下图所示，不是所有路径和步骤都要执行:在开始之前需要评估哪些步骤要执行（在评估业务状态）
如果你面临的业务领域是客户很成熟的业务，客户没有改进业务的打算，则选第一条。
如果业务领域有改进的打算，与客户一起，建模结果需得到客户确认，执行第二条路径。
如果客户有通过信息管理改革其业务的打算，则执行第三条。信息系统不仅要实现业务，还要管理业务，负担起监控和推进管理政策的作用。
如果你面临的业务领域大部分都很清楚或者有成型的系统，则执行第四步。
（在统一过程没有专门定义概念模型的建立过程）
活动集和工件集
统一过程定义了业务建模工作流程中的主要角色以及应当执行的活动。
上图指出了为了完成一个完整的业务模型需要执行的活动。上图6.2主要列出了业务建模工作的检查点。
在统一过程中，完整的业务建模完成后可以得到下图的工件。
以上工件还需分清，哪些是可交付工件，哪些是实施工件集。可交付物正常以文档形式体系，交给客户成为项目的正是附件，实施工件只是建模时使用到。图6.3中业务流程分析员都是可交付，而业务设计员对应的工件都是实施工件。
业务建模的作用主要是用来了解对系统的需求，确定设计模型中的实体类。
二、系统建模工作流
系统建模就是通常意义上的需求过程，它主要使用系统用例模型来建立。系统建模也在统一过程中先启阶段开始，精化阶段细化。
工作流程图:
下面是统一过程对系统建模活动的指南。
首先我们需要先分析问题，去理解涉众的需求，提出一些实现，从业务角度界定解决方案。然后去定义系统，在系统定义的初期要确定以下内容: 需求构成、文档格式、需求的优先级和预计工作量等。管理项目的规模、需求变更等等，可以看图。
活动集和工件集
在统一过程中，上面的活动完成后，可以得到下面的工件集:
下面分别对上面的工件概念做一些解释:
前景:特别适用于描述产品型项目，描述即将开发的软件的商业木匾以及达到此商业目标的产品应当具有的特征、涉众需求分析、产品说明、产品要求等等。
凡是跟项目有关系的人或者组织或系统，都是涉众。先发现和定义涉众，然后再调查他们的请求。
软件需求规约，就是我们常说的需求规格说明书。它需要将用例模型（包括用例规约、用例视图等）和补充条约、系统界面原型等集中起来，作为一份完整的需求规格说明书。
用例示意板，就是用来描述界面如何使用用例这一信息。
系统建模的目的:能够使系统开发人员能够更清楚的了解系统需求，定义系统边界（限定），为计划迭代的技术内容提供基础。
系统建模工作流程与其他工作流程的关系为：
业务建模工作流程为系统建模工作流程提供了业务规则、业务用例模型和业务对象模型，包括领域模型和系统的组织环境。
分析设计工作流程从系统建模工作流程中获取主要输入（用例模型和词汇表）.在分析设计中发现用例模型的缺陷。
总结:系统建模工作流程规定在计算机中将如何实现这些业务，应当理解，系统模型是业务模型到计算机系统的映射，我们可以通过系统建模得到系统开发的范围，明确计算机要做什么。
三、分析设计建模工作流
分析设计建模即我们所熟知的概要设计和详细设计过程，主要使用分析模型和设计模型来完成设计过程。
对于很多还没习惯以架构为导向的开发模型的开发人员来说，上图的流程估计跟实际工作中开发的相差很远，在现实项目中，很多人估计只有两部分设计，界面设计与数据库设计。
可是统一过程本身就是一个重量级的过程，比较适应大型或超大型的项目。下面是统一过程定义的分析和设计过程做一个概览:
统一过程中将设计和分析合并为一个流程如下图所示：
-
首先需要先定义和改进架构，下面是定义架构的流程图
改进备选架构的流程图:
第三步，设计组件
统一过程中，组件是实施单元，他们被安放在某一位置然后由架构驱动执行。如果项目不存在可复用的基础，没有独立部署的要求，定义组件就成了鸡肋。大部分系统中可复用的部分都是系统范围的，例如日志处理、事务管理、异常处理等，但这些部分通常可以被处理为架构或者框架的一部分，其他部分没有太多复用价值。因此定义组件要用在需要用的地方。
还有组件的定义是一个复用的单元，在统一过程中还区分了实时组件和非实时组件，分别对应实时系统和非实时系统。
实时系统就是指系统对响应时间和可靠性有着严格要求的系统，许多工业软件都有实时性要求。
还有一种就是设计数据库相关的内容。
主要的活动集以及工件集
分析设计工作流程的主要角色以及他们应当执行的活动如下图所示:
四、实施建模工作流
实施建模的目的，是建立组件及其所在的实施子系统的集合。组件中既有可交付文件，又有用来生成可交付文件的组件。换句话说，实施模型，将开发工作分成许多工作包，因而可以协作生产这些工作包，然后组装他们以形成最终系统。
统一过程定义实施建模的工作流程如图所示:
在一个以架构为导向以迭代为生命周期的项目里，建立实施模型是很有意义的，通过实施模型，可以允许系统在多次迭代中逐步完善，每一次迭代组装出系统的一个部分直至完成。不过前提条件是设计分析过程中足够完善，以至于可以非常清楚地定义出系统地每个组件、实现这些组件的类、组件之间的依赖、接口和通信标准。
统一过程定义的实施建模的活动集和工件集如下图所示:
以上就是今天UML学习的一些内容了，明天会整理一些实践性的例子。
