《大象：thinking in uml 》(第二版) 6章 统一过程核心工作流简介

只供参考，喜欢请支持正版图书

本章作者将列举出使用UML最多，也最为常用的几个工作流程。它们是：
■　业务建模工作流程
■　系统建模工作流程
■　分析设计工作流程
■　实施建模工作流程

6.1 业务建模工作流程

6.1.1 工作流程

统一过程定义业务建模的工作流程如图6.1所示
在此工作流程中，并非所有的路径和步骤都需要执行。在开始业务建模工作之前，应当评估并决定采用哪个（些）路径和哪些步骤。这项工作在“评估业务状态”这一活动步骤中完成

■　如果你所面临的业务领域是客户已经很成熟的业务，客户并无改进其业务流程的打算，那么业务建模就只需要执行第一条路径，把当前业务说清楚就行了。

■　如果你面临的业务领域客户有改进其业务流程的打算，那么业务建模需要执行第二条路径。这项工作必须与客户一起完成，建模过程和结果都必须与客户达成一致意见并得到确认。

■　如果你面临的业务领域客户有通过信息系统管理改革其业务模式的打算，那么业务建模需要执行第三条路径。这时信息系统不仅仅是实现业务，还需要管理业务，负担起监控和推进管理层管理政策的作用。这项工作必须与客户，尤其是管理层客户一起完成，以保证业务建模的结果符合管理层的管理政策。

■　如果你面临的业务领域大部分都已经很清楚，或者之前已经有比较成型的系统，或者大部分业务都很简单，可以只针对还不太清楚的领域建立模型。在建立业务模型的过程中发现某个领域比较复杂或者非常重要，则应当执行第四条路径。

6.1.2 活动集和工件集

在统一过程中，完整的业务建模工作完成后，应当得到如图6.3所示的工件集

6.1.3 业务建模的目标和场景

根据环境和需求的不同，业务建模工作可能有不同的规模。以下列出了六种这样的场景：
6.1.3.1　场景#1——组织图
6.1.3.2　场景#2——领域建模
6.1.3.3　场景#3——单业务多系统
6.1.3.4　场景#4——通用业务模型
6.1.3.5　场景#5——新业务
6.1.3.6　场景#6——修改

6.2 系统建模工作流程

6.2.1 工作流程

统一过程中定义系统建模的工作流程如图6.4所示

6.2.2 活动集和工件集

6.3 分析设计建模工作流程

6.3.2 活动集和工件集

6.3.4 推荐的分析设计工作流程简介

6.4 实施建模工作流程

6.4.2 活动集和工件集

6.4.3 推荐的实施建模工作流程

每一次迭代的结果都应当是一个可运行的系统，而不是类似核心模块这种不可执行的模块。如果某次迭代只产生出一个核心模块，它不能被测试（按用例场景测试）、不能被验证（被证明实现了用例场景）、更不能先期交付客户做试运行，那么这个迭代基本上是没有太大意义的。

采用实施模型的思想，以用例为基础来分工，因为一个用例就是一个可独立执行的单元，所以每一次迭代的目标可定义为实现哪些用例。分工时最先考虑的是哪些逻辑组件（这里的组件是指模块、子系统、库等含义）可以实现这些用例，哪怕实现这些用例的逻辑组件横跨了许多模块、业务、小组。为了快速搭建出一个可运行的系统，可以只实现一个类的部分功能。甚至所谓的核心模块也不需要最先开发完成，只需开发出与实现用例相关那一部分。

第三，项目时间也许总是不够的。按照传统的项目运作模式，当距离项目期限越来越近时，项目经理可能会为无法交出一个满意系统而焦头烂额，赶工的结果通常是以降低质量为代价的。而按用例的分法，即使没有完成全部系统，也至少完成了核心业务，项目经理不必过于担心客户会暴跳如雷。想像一下，在项目期限到来的时候，是交付给客户一个虽然看上去全部完成但却千疮百孔几乎不可使用的系统，还是交付给客户一个虽然没有全部完成但核心模块已经稳定和强壮的系统会让客户比较容易接受？

只供参考，喜欢请支持正版图书