剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
文章
用UML做好系统分析
作者 邱郁惠 发布于 2008年6月19日 下午11时42分
使用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的类图：
- 套用交易模式，并且经过调整之后，系统分析员可以获得初步的静态结构。
- 分析PIM-2的状态图之后，系统分析员可以为类增加属性及操作。
- 分析PIM-1搜集来的窗体，系统分析员可以为类增加更多的属性。
- 经过PIM-4的序列图，系统分析员可以为类增加更多的操作，并且描述操作的方法。
PIM-4：定义操作及方法
在PIM-4中，系统分析员可以用序列图来表达，系统内部一群对象合力完成某一个系统用例时，执行期间的交互情形。之后，序列图可能通过设计师之手，进行调整，并且成为程序员最关切的设计图之二（另一张是类图）。程序员通常会按照序列图的内容，编写出方法的源代码雏型。
此外，PIM-1的系统用例叙述和PIM-3的类图，对PIM-4的序列图有不可或缺的贡献。从PIM-1的系统用例叙述中，系统分析员可以分析出系统流程。而在PIM-3的类图中，系统分析员定义出系统内部的静态结构。随后，到了PIM-4的序列图时，则结合了系统用例以及静态结构两者。
系统分析员通过序列图的思考与表达，试图安排依据类们所生成的一群对象之间的交互，让这一群对象可以合力完成某一个系统用例。同时，在序列图中，一群对象交互所引发的操作，则可以反馈给类图，定义出更多的操作及属性，甚至发现之前未发现的其他类及关系。
系统分析员可参考下述步骤来绘制序列图：
- 扮演启动者的执行者对象放置于序列图最左方；扮演支持者的执行者对象放至于序列图的最右方。
- 针对系统用例叙述里所记载每项流程步骤，判断执行时需要使用到哪些数据，且可指派拥有该数据的对象负责该项工作。
- 试着执行序列图，以便调整流程，并且为操作加上参数。
- 把绘制序列图时所找到的操作及属性，反馈给类图。
以“网络申购单笔基金”系统用例之主要流程为例，我们示范绘制出如图2-8所示的序列图。
最后，系统分析员可以试着执行一次序列图的流程，并且为操作加上参数。增加输入（in）及输出（out）参数如下：
- 查询托售基金清单（out 基金名称清单）
- 查询基金名称（out 基金名称，基金代号）
- 查询扣款账号（out 扣款账号）
- 单笔申购基金（in 基金代号，申购金额）
- 计算手续费（in 申购金额，out 手续费）
- 查询银行折扣（out 银行折扣）
- 查询基金管理费（out 基金管理费）
- 查询综存账户余额（out 综存账户余额）
- 查询综存账户余额（in 扣款账号，out 综存账户余额）
- 确认单笔申购（out 凭证号码）
- 扣款（）
- 扣款（in 交易金额）
- 设定申购日期（）
- 产生交易编号（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章《基金模拟项目》
这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
deshi xiao
发表于
2008年6月21日 上午9时58分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
Tobato King
发表于
2008年6月24日 下午8时56分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
deshi xiao
发表于
2008年6月25日 上午6时17分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
郁惠 邱
发表于
2008年6月25日 上午6时47分
赞成！这是一种很好的心态
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午8时43分
Re: 这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
发表人
qian anchuan
发表于
2008年7月3日 下午9时59分
UML 应用方法的创新
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午8时33分
能否介绍一下你的经验和思考？
发表人
Charlie Zhang（张恂）
发表于
2008年6月25日 上午9时0分
思考
发表人
Tobato King
发表于
2008年6月26日 下午9时30分
Re: 思考
发表人
Tobato King
发表于
2008年6月26日 下午9时32分
Re: 思考
发表人
Jacky Li
发表于
2008年6月29日 上午1时0分
Re: 思考
发表人
wonder qi
发表于
2008年7月11日 上午1时12分
使用uml工具来产生文档
发表人
jim han
发表于
2008年6月26日 下午8时24分
很好的分析过程与方法
发表人
hua gao
发表于
2008年6月25日 上午5时32分
-
我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。
-
deshi xiao 还有更好的方法么?我觉得文档成本比较高,在需求变化比较快的大型项目中,设计文档的维护是一个很头疼的问题.或者说有没有可能提供更好的工具可以降低文档的维护量?
-
通过上述分析过程与方法,可以使 经验/随意的 分析方法/过程 系统化/过程化、标准化/规范化、模式化/模型化，值得分析设计人员认真学习研究。
-
我是以我的技术经验来判断以上文章的，标准化，规范化肯定谁都希望，还有人希望过程自动化呢。可实现这样的系统，现在都在变化中，条件，需求，任务。像文中针对正式的业务系统这样分析，当然没得说，看上去很漂亮，但价值除了好看之外，他的通用性如何呢。所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。
-
謝謝各位對這本書提出這麼多看法。
我想這本書的內容有它可取之處，也會有在實務上難以配合之處。在台灣，很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。
我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。 -
deshi xiao：“他的通用性如何呢”
本书好像介绍的是<strong>一种</strong> MDA 的建模方式，我感觉国内外 MDA 还没有普及，即便是 MDA 应用也未必只有一种标准方式，所以我不觉得本书的方法具有广泛的通用性。
当然，我们未必要追求广泛的通用性，有专用性也不错。那么本书介绍的方法是否“专门”适合国内的应用环境呢？我感觉也未必。
但作为一种观点和方法，我觉得作者的思路值得借鉴和参考。
deshi xiao：“所以就中国的软件开发业来说，UML的用处确实有用，但我们不能照搬别人的分析方式，应该用好UML这工具，但分析方式需要创新，并适合中国人的理解方式。
”
赞同，西方再成熟的技术在中国也有一个落地的问题，方式、方法的创新很重要。能否介绍一下你在这方面的经验？
张恂提出的 UML 太极建模 也是出于这个目的，欢迎有兴趣的朋友一起研究。
OOAD*UML 教练 张恂
www.zhangxun.com -
作者说的很实在和诚恳，不错。
“我想這本書的內容有它可取之處，也會有在實務上難以配合之處。”
“很多公司閱讀這本書，理解了之後，將書中的步驟修修改改，形成符合自己公司文化的程序，這是我最樂於見到的。”
“我從未希望各位完全按著這本書的方式進行，這絕對會有問題，因為每個公司、團隊的文化不同，不可能有一套統一的開發流程，我謹希望這本書可以有拋磚引玉之效，引出您們寶貴的開發流程。”
OOAD*UML 教练 张恂
www.zhangxun.com -
2008年6月21日 上午9时58分 发表人 deshi xiao
这样作分析，成本很高，对系统分析员的要求很高，如何保证质量
我们知道，经济活动有审计，你这个系统分析如何审计。以上的例子适应领域应该是大型项目，但我担心如此复杂的业务模型是否能保证顺利执行。
初看之下，本书的分析方法成本并不高，有些是必要的步骤，这样的业务模型还算简单，中小型项目估计也是可以尝试的。
缺点在于，只做到 PIM 就没下文了，好像没把 MDA 的完整流程走完。任何分析、设计模型，如果脱离实际代码，都可能带来风险。所以大家会有能否“顺利执行”的疑问。
你说的审计是不是 audit，自动审计还好，如果人工审计，往往也会增加成本。
估计你有很多话想说，能否介绍一下你的经验和思考，或者更好的、成本更低廉的让系统分析员可以保证质量的方法？
OOAD*UML 教练 张恂
www.zhangxun.com -
实际上项目的文档其实就是这些uml图，但用户估计看不懂uml，他们需要的是文字性的word文档，我的经验是当用户需要提交文档的时候，通过uml工具输出一份文档就行了，而且这些文档用完了就扔，不必专人维护，如果用户对文档的格式不习惯，可以考虑花点功夫定制一下uml工具的报表模板来规范输出的格式，然后辅以专人进行修订，一般说来没什么问题
-
这样自上而下，由外到内，由粗到细的分析方式本身是没有问题的,甚至从哲学的观点上来看都是很科学的.
我感觉出问题的地方是我们抱着"为了保证留下文档","今后有人能够看明白","别人能接手"等等很"自然"的想法,我们企图去[记录整个问题的分析过程],希望每一步都完美的被记录.
1.开发的整个过程可能包括业务用例定义->业务用例分析->系统用例定义->系统用例分析->分析类图->分析序列图...在这个过程中出现的是成[金字塔状态的成本消耗].
2.在现实开发中,企图一次就得到最终的答案是很难的.尽管定义的过程是线性的:CIM->PIM->PSM,事实上我们往往需要在几个过程之间进行反复,
分析->设计->Coding->修改分析->修改代码.由于抱着不肯抛弃过程产物,文档驱动等想法,我们甚至企图去记录整个反复的分析过程,这是需要花费大量成本的工作!
相当于把成本金字塔放大了N倍.到最后可能把自己陷入到一堆"过程垃圾"中.
因此,我认为:抛弃记录过程产物的想法,轻装上阵,以交流替代文档,用多种方式:图片\DV\文本等,只记录"必须的能帮助理解的资料",在迭代后期加入小的文档整理的过程(这个时候是效率最高的,屏蔽了很多分析中的杂质) 会是一个比较好的实践.
另:大型项目或行业项目中,以软件产品线为主导思想,在建立适当的库(规则库,业务流程库,组件库等)为基础上搭建特定领域的辅助分析设计工具,能在很大程度降低整个开发的成本. -
晕了, 段落贴没了
-
可以用两个br来分段:)
-
可工作的软件，胜过面面俱到的文档
-
tobato说的有道理，大多数时候模型的维护要比代码的维护代价大的多。
.gif)
14 条回复
回复