用UML做好系统分析.docx
- 文档编号:6274488
- 上传时间:2023-05-09
- 格式:DOCX
- 页数:11
- 大小:21.58KB
用UML做好系统分析.docx
《用UML做好系统分析.docx》由会员分享,可在线阅读,更多相关《用UML做好系统分析.docx(11页珍藏版)》请在冰点文库上搜索。
用UML做好系统分析
用UML做好系统分析
CIM-1:
定义业务流程
定义及分析业务流程(BusinessProcess)是为了尽快理清系统范围,以便估算开发成本及时间,可不是为了要改造业务流程。
系统分析员千万别误解了此步骤的目的。
所以,系统分析员在定义及分析业务流程时,要记得挑选跟系统有关的业务流程。
CIM-1定义业务流程的生成,主要有如下的业务用例图和简述。
请看图2-1的业务用例图,图中的每一个业务用例代表一条业务流程,业务执行者则代表位于企业外但会启动或参与业务流程的人。
投资人到银行临柜申购基金,启动了银行内部的一段关于申购基金的业务流程。
再者,投资人也可能临柜办理赎回基金,这又引发了另一条业务流程。
至于业务用例简述,简洁扼要即可,我们主要用它来记录和区分业务流程。
CIM-2:
分析业务流程
通过CIM-1圈出了系统将参与的业务流程之后,针对每一个业务用例,系统分析员得开始分析它的工作流程,并且绘制活动图(ActivityDiagram)与业务人员取得共识。
随后到了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的系统执行者(SystemActor)。
针对上述的图2-2一般流程的活动图,我们分析得出如图2-3的系统用例图,以及下述的用例简述。
PIM-1:
分析系统流程
在CIM阶段,系统分析员大约花1~2周的时间,尽快生成初步的系统用例,以便让相关的决策人员可以从中挑选出首期开发的系统用例,而这也就是首期的系统范围。
随后,项目正式进入PIM阶段,也是正式进入分析阶段,所以系统分析员将投入更多的时间,针对首期的系统用例详述规格,作为正式需求文件的一部分,也作为业务人员与开发人员之间的沟通文件。
所以,系统分析员在PIM-1的主要工作,将针对每一个系统用例,分析其内部细节,并编写详尽的系统用例叙述(UCDescription)。
UML并未提出标准的叙述格式可供遵守,不过系统分析员可以在网络上找到许多实用的用例叙述格式,或者翻阅一些UML或用例相关书籍,也可以发现许多很有特色的用例叙述格式。
此处,我们示范编写“网络申购单笔基金”和“网络申购定期定额基金”的系统用例叙述,如下图2-4和图2-5所示:
PIM-2:
分析业务规则
企业通过一组规则(BuisnessRules)来控制整体的运作,包括人员、流程、系统、概念的运作,皆受制于业务规则。
由此足见业务规则之重要,所以早从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的序列图,系统分析员可以为类增加更多的操作,并且描述操作的方法。
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-DrivenArchitecture)开发程序,作为专业分工的依据,因此系统分析员的工作聚焦于CIM与PIM阶段,至于PSM及编码阶段,则交由其他的设计师负责之。
MDA主要将生成的UML模型,分为下列三个阶段:
∙CIM(ComputationIndependentModel)──聚焦于系统环境及需求,但不涉及系统内部的结构与运作细节。
∙PIM(PlatformIndependentModel)──聚焦于系统内部细节,但不涉及实现系统的具体平台(Platform)。
∙PSM(PlatformSpecificModel)──聚焦于系统落实于特定具体平台的细节。
例如,Spring、EJB2或.NET都是一种具体平台。
因此,系统分析员执行了前述的CIM与PIM步骤,并且获得高质量的生成之后,设计师会依据具体平台进一步生成PSM阶段的设计,并交由程序员按图编码,编写出适用于特定具体平台的代码。
本文节选自机械工业出版社新推出的《系统分析师UML实务手册》中的第2章《做好系统分析》。
《系统分析师UML实务手册》通过一个完整的仿真实例,介绍了从需求到生成UML的用例图及其叙述、活动图、类图、序列图和状态图等,一应俱全,过程细腻,步骤详细。
主要内容包括:
定义业务流程、分析业务流程、定义系统范围、分析系统流程、分析业务规则、定义静态结构、定义操作及方法、基金模拟项目、语音备忘器等。
与此同时,机械工业出版社还授权InfoQ中文站独家为大家提供额外的样章进行试读:
欢迎下载第10章《基金模拟项目》
14条回复
关注此讨论回复
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量发表人xiaodeshi发表于2008年6月21日上午9时58分
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量发表人KingTobato发表于2008年6月24日下午8时56分
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量发表人xiaodeshi发表于2008年6月25日上午6时17分
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量发表人邱郁惠发表于2008年6月25日上午6时47分
赞成!
这是一种很好的心态发表人ZhangCharlie发表于2008年6月25日上午8时43分
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量发表人anchuanqian发表于2008年7月3日下午9时59分
UML应用方法的创新发表人ZhangCharlie发表于2008年6月25日上午8时33分
能否介绍一下你的经验和思考?
发表人ZhangCharlie发表于2008年6月25日上午9时0分
思考发表人KingTobato发表于2008年6月26日下午9时30分
Re:
思考发表人KingTobato发表于2008年6月26日下午9时32分
Re:
思考发表人LiJacky发表于2008年6月29日上午1时0分
Re:
思考发表人qiwonder发表于2008年7月11日上午1时12分
使用uml工具来产生文档发表人jimhan发表于2008年6月26日下午8时24分
很好的分析过程与方法发表人gaohua发表于2008年6月25日上午5时32分
按日期倒序排列
1.返回顶部
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
2008年6月21日上午9时58分发表人xiaodeshi
我们知道,经济活动有审计,你这个系统分析如何审计。
以上的例子适应领域应该是大型项目,但我担心如此复杂的业务模型是否能保证顺利执行。
回复
2.返回顶部
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
2008年6月24日下午8时56分发表人KingTobato
deshixiao还有更好的方法么?
我觉得文档成本比较高,在需求变化比较快的大型项目中,设计文档的维护是一个很头疼的问题.或者说有没有可能提供更好的工具可以降低文档的维护量?
回复
3.返回顶部
很好的分析过程与方法
2008年6月25日上午5时32分发表人gaohua
通过上述分析过程与方法,可以使经验/随意的分析方法/过程系统化/过程化、标准化/规范化、模式化/模型化,值得分析设计人员认真学习研究。
回复
4.返回顶部
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
2008年6月25日上午6时17分发表人xiaodeshi
我是以我的技术经验来判断以上文章的,标准化,规范化肯定谁都希望,还有人希望过程自动化呢。
可实现这样的系统,现在都在变化中,条件,需求,任务。
像文中针对正式的业务系统这样分析,当然没得说,看上去很漂亮,但价值除了好看之外,他的通用性如何呢。
所以就中国的软件开发业来说,UML的用处确实有用,但我们不能照搬别人的分析方式,应该用好UML这工具,但分析方式需要创新,并适合中国人的理解方式。
回复
5.返回顶部
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
2008年6月25日上午6时47分发表人邱郁惠
謝謝各位對這本書提出這麼多看法。
我想這本書的內容有它可取之處,也會有在實務上難以配合之處。
在台灣,很多公司閱讀這本書,理解了之後,將書中的步驟修修改改,形成符合自己公司文化的程序,這是我最樂於見到的。
我從未希望各位完全按著這本書的方式進行,這絕對會有問題,因為每個公司、團隊的文化不同,不可能有一套統一的開發流程,我謹希望這本書可以有拋磚引玉之效,引出您們寶貴的開發流程。
回复
6.返回顶部
UML应用方法的创新
2008年6月25日上午8时33分发表人ZhangCharlie
deshixiao:
“他的通用性如何呢”
本书好像介绍的是一种MDA的建模方式,我感觉国内外MDA还没有普及,即便是MDA应用也未必只有一种标准方式,所以我不觉得本书的方法具有广泛的通用性。
当然,我们未必要追求广泛的通用性,有专用性也不错。
那么本书介绍的方法是否“专门”适合国内的应用环境呢?
我感觉也未必。
但作为一种观点和方法,我觉得作者的思路值得借鉴和参考。
deshixiao:
“所以就中国的软件开发业来说,UML的用处确实有用,但我们不能照搬别人的分析方式,应该用好UML这工具,但分析方式需要创新,并适合中国人的理解方式。
”
赞同,西方再成熟的技术在中国也有一个落地的问题,方式、方法的创新很重要。
能否介绍一下你在这方面的经验?
张恂提出的UML太极建模也是出于这个目的,欢迎有兴趣的朋友一起研究。
OOAD*UML教练张恂
回复
7.返回顶部
赞成!
这是一种很好的心态
2008年6月25日上午8时43分发表人ZhangCharlie
作者说的很实在和诚恳,不错。
“我想這本書的內容有它可取之處,也會有在實務上難以配合之處。
”
“很多公司閱讀這本書,理解了之後,將書中的步驟修修改改,形成符合自己公司文化的程序,這是我最樂於見到的。
”
“我從未希望各位完全按著這本書的方式進行,這絕對會有問題,因為每個公司、團隊的文化不同,不可能有一套統一的開發流程,我謹希望這本書可以有拋磚引玉之效,引出您們寶貴的開發流程。
”
OOAD*UML教练张恂
回复
8.返回顶部
能否介绍一下你的经验和思考?
2008年6月25日上午9时0分发表人ZhangCharlie
2008年6月21日上午9时58分发表人deshixiao
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
我们知道,经济活动有审计,你这个系统分析如何审计。
以上的例子适应领域应该是大型项目,但我担心如此复杂的业务模型是否能保证顺利执行。
初看之下,本书的分析方法成本并不高,有些是必要的步骤,这样的业务模型还算简单,中小型项目估计也是可以尝试的。
缺点在于,只做到PIM就没下文了,好像没把MDA的完整流程走完。
任何分析、设计模型,如果脱离实际代码,都可能带来风险。
所以大家会有能否“顺利执行”的疑问。
你说的审计是不是audit,自动审计还好,如果人工审计,往往也会增加成本。
估计你有很多话想说,能否介绍一下你的经验和思考,或者更好的、成本更低廉的让系统分析员可以保证质量的方法?
OOAD*UML教练张恂
回复
9.返回顶部
使用uml工具来产生文档
2008年6月26日下午8时24分发表人jimhan
实际上项目的文档其实就是这些uml图,但用户估计看不懂uml,他们需要的是文字性的word文档,我的经验是当用户需要提交文档的时候,通过uml工具输出一份文档就行了,而且这些文档用完了就扔,不必专人维护,如果用户对文档的格式不习惯,可以考虑花点功夫定制一下uml工具的报表模板来规范输出的格式,然后辅以专人进行修订,一般说来没什么问题
回复
10.返回顶部
思考
2008年6月26日下午9时30分发表人KingTobato
这样自上而下,由外到内,由粗到细的分析方式本身是没有问题的,甚至从哲学的观点上来看都是很科学的.
我感觉出问题的地方是我们抱着"为了保证留下文档","今后有人能够看明白","别人能接手"等等很"自然"的想法,我们企图去[记录整个问题的分析过程],希望每一步都完美的被记录.
1.开发的整个过程可能包括业务用例定义->业务用例分析->系统用例定义->系统用例分析->分析类图->分析序列图...在这个过程中出现的是成[金字塔状态的成本消耗].
2.在现实开发中,企图一次就得到最终的答案是很难的.尽管定义的过程是线性的:
CIM->PIM->PSM,事实上我们往往需要在几个过程之间进行反复,
分析->设计->Coding->修改分析->修改代码.由于抱着不肯抛弃过程产物,文档驱动等想法,我们甚至企图去记录整个反复的分析过程,这是需要花费大量成本的工作!
相当于把成本金字塔放大了N倍.到最后可能把自己陷入到一堆"过程垃圾"中.
因此,我认为:
抛弃记录过程产物的想法,轻装上阵,以交流替代文档,用多种方式:
图片\DV\文本等,只记录"必须的能帮助理解的资料",在迭代后期加入小的文档整理的过程(这个时候是效率最高的,屏蔽了很多分析中的杂质)会是一个比较好的实践.
另:
大型项目或行业项目中,以软件产品线为主导思想,在建立适当的库(规则库,业务流程库,组件库等)为基础上搭建特定领域的辅助分析设计工具,能在很大程度降低整个开发的成本.
回复
11.返回顶部
Re:
思考
2008年6月26日下午9时32分发表人KingTobato
晕了,段落贴没了
回复
12.返回顶部
Re:
思考
2008年6月29日上午1时0分发表人LiJacky
可以用两个br来分段:
)
回复
13.返回顶部
Re:
这样作分析,成本很高,对系统分析员的要求很高,如何保证质量
2008年7月3日下午9时59分发表人anchuanqian
可工作的软件,胜过面面俱到的文档
回复
14.返回顶部
Re:
思考
2008年7月11日上午1时12分发表人qiwonder
tobato说的有道理,大多数时候模型的维护要比代码的维护代价大的多。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 做好 系统分析
![提示](https://static.bingdoc.com/images/bang_tan.gif)