使用UML如何能让我们做好系统分析的工作呢？就让我们通过本章的基金模拟项目，先睹 为快，抢先体验一番。

CIM-1：定义业务流程

定义及分析业务流程（Business Process）是为了尽快理清系统范围，以便估算开发成本及时间，可不是为了要改造业务流程。系统分析员千万别误解了此步骤的目的。所以，系统分析员在定义及分析业务流程时，要记得挑选跟系统有关的业务流程。

CIM-1定义业务流程的生成，主要有如下的业务用例图和简述。请看图2-1的业务用例图，图中的每一个业务用例代表一条业务流程，业务执行者则代表位于企业外但会启动或参与业务流程的人。投资人到银行临柜申购基金，启动了银行内部的一段关于申购基金的业务流程。再者，投资人也可能临柜办理赎回基金，这又引发了另一条业务流程。

至于业务用例简述，简洁扼要即可，我们主要用它来记录和区分业务流程。

CIM-2：分析业务流程

通过CIM-1圈出了系统将参与的业务流程之后，针对每一个业务用例，系统分析员得开始分析它的工作流程，并且绘制活动图（Activity Diagram）与业务人员取得共识。随后到了CIM-3时，才能够依此定义出系统可以协助之处，并且规划出系统范围。

此处，我们挑选一般的申购基金流程当示范，并绘制出如图2-2所示的活动图，展示了单笔申购基金的一般交易流程。

CIM-3：定义系统范围

经过了CIM-1的定义业务流程，以及CIM-2的分析业务流程之后，终于进入到CIM-3这场压轴戏了。CIM-1和CIM-2的生成文件，跟CIM-3的生成文件之间，有如下的关联性：

• CIM-2活动图中的每一个动作，都可能成为CIM-3的系统用例。
• CIM-1中的业务执行者，以及CIM-2中的动作负责人，都可能成为CIM-3的系统执行者（System Actor）。

针对上述的图2-2一般流程的活动图，我们分析得出如图2-3的系统用例图，以及下述的用例简述。

PIM-1：分析系统流程

在CIM阶段，系统分析员大约花1～2周的时间，尽快生成初步的系统用例，以便让相关的决策人员可以从中挑选出首期开发的系统用例，而这也就是首期的系统范围。

随后，项目正式进入PIM阶段，也是正式进入分析阶段，所以系统分析员将投入更多的时间，针对首期的系统用例详述规格，作为正式需求文件的一部分，也作为业务人员与开发人员之间的沟通文件。

所以，系统分析员在PIM-1的主要工作，将针对每一个系统用例，分析其内部细节，并编写详尽的系统用例叙述（UC Description）。UML并未提出标准的叙述格式可供遵守，不过系统分析员可以在网络上找到许多实用的用例叙述格式，或者翻阅一些UML或用例相关书籍，也可以发现许多很有特色的用例叙述格式。

此处，我们示范编写“网络申购单笔基金”和“网络申购定期定额基金”的系统用例叙述，如下图2-4和图2-5所示：

PIM-2：分析业务规则

企业通过一组规则（Buisness Rules）来控制整体的运作，包括人员、流程、系统、概念的运作，皆受制于业务规则。由此足见业务规则之重要，所以早从PIM-1的系统用例叙述，一直到此处的PIM-2状态图以及稍后的PIM-3类图，我们都会要求系统分析员必需通过这些UML图，记录且呈现重要的业务规则。

例如，在经过PIM-1的步骤之后，我们认为“定期定额申购”是很重要的业务对象，而且涉及许多重要的业务规则，所以决定为它绘制如图2-6的状态图，以便组织业务规则，同时也对定期定额申购有更深入的理解。

PIM-3：定义静态结构

在PIM-3中，系统分析员用类图来表达系统内部的静态结构。系统只有具备稳定且具弹性的静态结构，才能够顺应需求变更，迅速支撑多样化的系统用例。之后，类图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之一。程序员通常会按照类图的内容，来编写并组织源代码。

在PIM-3的过程中，系统分析员寻找操作绝对优先于寻找属性。因为属性随处可见，特别是从PIM-1搜集而来的窗体，里头多的是对象必须保存的属性。而寻找操作就没这么直接简单了，系统分析员必须多动脑筋才能定义出操作，所以先别管属性了，记得优先找操作。

进行PIM-3时，系统分析员可以通过下列步骤，建立出如图2-7的类图：

1. 套用交易模式，并且经过调整之后，系统分析员可以获得初步的静态结构。
2. 分析PIM-2的状态图之后，系统分析员可以为类增加属性及操作。
3. 分析PIM-1搜集来的窗体，系统分析员可以为类增加更多的属性。
4. 经过PIM-4的序列图，系统分析员可以为类增加更多的操作，并且描述操作的方法。
5.  

PIM-4：定义操作及方法

在PIM-4中，系统分析员可以用序列图来表达，系统内部一群对象合力完成某一个系统用例时，执行期间的交互情形。之后，序列图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之二（另一张是类图）。程序员通常会按照序列图的内容，编写出方法的源代码雏型。

此外，PIM-1的系统用例叙述和PIM-3的类图，对PIM-4的序列图有不可或缺的贡献。从PIM-1的系统用例叙述中，系统分析员可以分析出系统流程。而在PIM-3的类图中，系统分析员定义出系统内部的静态结构。随后，到了PIM-4的序列图时，则结合了系统用例以及静态结构两者。

系统分析员通过序列图的思考与表达，试图安排依据类们所生成的一群对象之间的交互，让这一群对象可以合力完成某一个系统用例。同时，在序列图中，一群对象交互所引发的操作，则可以反馈给类图，定义出更多的操作及属性，甚至发现之前未发现的其他类及关系。

系统分析员可参考下述步骤来绘制序列图：

1. 扮演启动者的执行者对象放置于序列图最左方；扮演支持者的执行者对象放至于序列图的最右方。
2. 针对系统用例叙述里所记载每项流程步骤，判断执行时需要使用到哪些数据，且可指派拥有该数据的对象负责该项工作。
3. 试着执行序列图，以便调整流程，并且为操作加上参数。
4. 把绘制序列图时所找到的操作及属性，反馈给类图。

以“网络申购单笔基金”系统用例之主要流程为例，我们示范绘制出如图2-8所示的序列图。

最后，系统分析员可以试着执行一次序列图的流程，并且为操作加上参数。增加输入（in）及输出（out）参数如下：

1. 查询托售基金清单（out 基金名称清单）
2. 查询基金名称（out 基金名称，基金代号）
3. 查询扣款账号（out 扣款账号）
4. 单笔申购基金（in 基金代号，申购金额）
5. 计算手续费（in 申购金额，out 手续费）
6. 查询银行折扣（out 银行折扣）
7. 查询基金管理费（out 基金管理费）
8. 查询综存账户余额（out 综存账户余额）
9. 查询综存账户余额（in 扣款账号，out 综存账户余额）
10. 确认单笔申购（out 凭证号码）
11. 扣款（）
12. 扣款（in 交易金额）
13. 设定申购日期（）
14. 产生交易编号（out 凭证号码）

由于，单笔申购和定期定额申购计算手续费的方法相同，所以系统分析员可以将单笔申购类里的“计算手续费”操作移至申购交易类，并汇总上述序列图所新增的操作与相关属性，更新类图如2-9所示。

在CIM与PIM之后

由于我们采用MDA（Model-Driven Architecture）开发程序，作为专业分工的依据，因此系统分析员的工作聚焦于CIM与PIM阶段，至于PSM及编码阶段，则交由其他的设计师负责之。MDA主要将生成的UML模型，分为下列三个阶段：

• CIM（Computation Independent Model）──聚焦于系统环境及需求，但不涉及系统内部的结构与运作细节。
• PIM（Platform Independent Model）──聚焦于系统内部细节，但不涉及实现系统的具体平台（Platform）。
• PSM（Platform Specific Model）──聚焦于系统落实于特定具体平台的细节。例如，Spring、EJB2或.NET都是一种具体平台。

因此，系统分析员执行了前述的CIM与PIM步骤，并且获得高质量的生成之后，设计师会依据具体平台进一步生成PSM阶段的设计，并交由程序员按图编码，编写出适用于特定具体平台的代码。

本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。

《系统分析师UML实务手册》通过一个完整的仿真实例，介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等，一应俱全，过程细腻，步骤详细。主要内容包括：定义业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。

与此同时，机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读：欢迎下载第10章《基金模拟项目》

来自：http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis

1.  

   这样作分析，成本很高，对系统分析员的要求很高，如何保证质量

   2008年6月21日 上午9时58分 发表人 deshi xiao

   我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。

2.  

   Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量

   2008年6月24日 下午8时56分 发表人 Tobato King

   deshi xiao 还有更好的方法么?我觉得文档成本比较高,在需求变化比较快的大型项目中,设计文档的维护是一个很头疼的问题.或者说有没有可能提供更好的工具可以降低文档的维护量?

3.  

   很好的分析过程与方法

   2008年6月25日 上午5时32分 发表人 hua gao

   通过上述分析过程与方法,可以使 经验/随意的 分析方法/过程 系统化/过程化、标准化/规范化、模式化/模型化，值得分析设计人员认真学习研究。

4.  

   Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量

   2008年6月25日 上午6时17分 发表人 deshi xiao

   我是以我的技术经验来判断以上文章的，标准化，规范化肯定谁都希望，还有人希望过程自动化呢。可实现这样的系统，现在都在变化中，条件，需求，任务。像文中针对正式的业务系统这样分析，当然没得说，看上去很漂亮，但价值除了好看之外，他的通用性如何呢。所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。

5.  

   Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量

   2008年6月25日 上午6时47分 发表人 郁惠 邱

   謝謝各位對這本書提出這麼多看法。 我想這本書的內容有它可取之處，也會有在實務上難以配合之處。在台灣，很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。 我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。

6.  

   UML 应用方法的创新

   2008年6月25日 上午8时33分 发表人 Charlie Zhang

   deshi xiao：“他的通用性如何呢”
   
   本书好像介绍的是一种 MDA 的建模方式，我感觉国内外 MDA 还没有普及，即便是 MDA 应用也未必只有一种标准方式，所以我不觉得本书的方法具有广泛的通用性。
   
   当然，我们未必要追求广泛的通用性，有专用性也不错。那么本书介绍的方法是否“专门”适合国内的应用环境呢？我感觉也未必。
   
   但作为一种观点和方法，我觉得作者的思路值得借鉴和参考。
   
   deshi xiao：“所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。 ”
   
   赞同，西方再成熟的技术在中国也有一个落地的问题，方式、方法的创新很重要。能否介绍一下你在这方面的经验？
   
   张恂提出的 UML 太极建模 也是出于这个目的，欢迎有兴趣的朋友一起研究。
   
   OOAD*UML 教练 张恂
   

7.  

   赞成！这是一种很好的心态

   2008年6月25日 上午8时43分 发表人 Charlie Zhang

   作者说的很实在和诚恳，不错。
   
   “我想這本書的內容有它可取之處，也會有在實務上難以配合之處。”
   
   “很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。”
   
   “我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。”
   
   OOAD*UML 教练 张恂 
   

8.  

   能否介绍一下你的经验和思考？

   2008年6月25日 上午9时0分 发表人 Charlie Zhang

   2008年6月21日 上午9时58分 发表人 deshi xiao
   
   这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
   
   我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。

   初看之下，本书的分析方法成本并不高，有些是必要的步骤，这样的业务模型还算简单，中小型项目估计也是可以尝试的。
   
   缺点在于，只做到 PIM 就没下文了，好像没把 MDA 的完整流程走完。任何分析、设计模型，如果脱离实际代码，都可能带来风险。所以大家会有能否“顺利执行”的疑问。
   
   你说的审计是不是 audit，自动审计还好，如果人工审计，往往也会增加成本。
   
   估计你有很多话想说，能否介绍一下你的经验和思考，或者更好的、成本更低廉的让系统分析员可以保证质量的方法？
   
   OOAD*UML 教练 张恂
   

9.  

   使用uml工具来产生文档

   2008年6月26日 下午8时24分 发表人 jim han

   实际上项目的文档其实就是这些uml图，但用户估计看不懂uml，他们需要的是文字性的word文档，我的经验是当用户需要提交文档的时候，通过uml工具输出一份文档就行了，而且这些文档用完了就扔，不必专人维护，如果用户对文档的格式不习惯，可以考虑花点功夫定制一下uml工具的报表模板来规范输出的格式，然后辅以专人进行修订，一般说来没什么问题

10.  

    思考

    2008年6月26日 下午9时30分 发表人 Tobato King

    这样自上而下，由外到内，由粗到细的分析方式本身是没有问题的,甚至从哲学的观点上来看都是很科学的. 我感觉出问题的地方是我们抱着"为了保证留下文档","今后有人能够看明白","别人能接手"等等很"自然"的想法,我们企图去[记录整个问题的分析过程],希望每一步都完美的被记录. 1.开发的整个过程可能包括业务用例定义->业务用例分析->系统用例定义->系统用例分析->分析类图->分析序列图...在这个过程中出现的是成[金字塔状态的成本消耗]. 2.在现实开发中,企图一次就得到最终的答案是很难的.尽管定义的过程是线性的:CIM->PIM->PSM,事实上我们往往需要在几个过程之间进行反复, 分析->设计->Coding->修改分析->修改代码.由于抱着不肯抛弃过程产物,文档驱动等想法,我们甚至企图去记录整个反复的分析过程,这是需要花费大量成本的工作! 相当于把成本金字塔放大了N倍.到最后可能把自己陷入到一堆"过程垃圾"中. 因此,我认为:抛弃记录过程产物的想法,轻装上阵,以交流替代文档,用多种方式:图片\DV\文本等,只记录"必须的能帮助理解的资料",在迭代后期加入小的文档整理的过程(这个时候是效率最高的,屏蔽了很多分析中的杂质) 会是一个比较好的实践. 另:大型项目或行业项目中,以软件产品线为主导思想,在建立适当的库(规则库,业务流程库,组件库等)为基础上搭建特定领域的辅助分析设计工具,能在很大程度降低整个开发的成本.

分类： 系统架构 设计模式