水稳基层纵向接缝处理:用UML做好系统分析

来源:百度文库 编辑:偶看新闻 时间:2024/04/28 10:19:01
2009-05-15 作者:邱郁惠 来源:infoq.com
使用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阶段的设计,并交由程序员按图编码,编写出适用于特定具体平台的代码。