用例分析技术学习体会(1)

                          用例分析学习笔记(1

     这几天看了《用例分析技术》一书,感觉收益颇大,以前虽然也会或一些程序的流程图但都是天马行空,从来没有什么规律与计划,想到了什么就添加上什么。在编码的时候就是丢三拉四,经常是在程序调试的时候,才想起忘了这个判断,那个条件等等,总是弄得人焦头烂额,很是疲惫不堪。

可是在经过用例分析技术的学习后,突然发现原来以前出现的那些问题可以这么简单地解决。特别是对于那些具有很多用户,处理流程特别复杂的系统,采用用例分析是一个不错的选择,它能为我们规划出一个清晰的整个事务的流程。废话不多说了:

在进行用例分析之前,必须了解项目的范围,也就是说要清晰确定系统的边界,一般来说系统的边界通过确定系统的执行者和用例来确定。

1.1执行者的确定

   执行者就是要与该系统交互的外部的所有事物。确定执行者的问题提示:谁使用系统?是安装系统?谁维护系统?哪些其他的系统要使用这个系统?谁为这个系统提供信息,水从这个系统获取信息等。

在确定执行者是必须注意到一个问题就是,我们并不关心执行者的数量,我们只关心执行者的种类,即任何执行相同事务的人或者系统都同意归纳为一个执行者。

1.2 用例的确定

   在确定了执行者之后,我们比须为每个执行者定义清晰的用例,即每个执行者对系统操作了些什么,对系统有什么样的功能需求,系统内部的变化要不要通知执行者。执行这怎样来操作系统,具体的流程是什么。在这个时候我们要对它有一个大略的分析。

   在确定了所有的用例之后,我们必须把所有的用例列在一张表上,并对其有详细的描述,同时如果用例过多,我们可以采用包图,对一个业务活动中的所有用例进行封装,使系统看起来更加的清晰。

1.3 归档用例

   这个是用例分析中非常重要的一步,我们必须对每个用例有清晰的认识,识别每个用例属于哪一个业务活动(其实在用例确定的包图就进行了用例归档)。

   同时我们还应该把用例分为基本路径与及可选路径,基本路径就是该业务活动正常操作时必须经过的路径。而可选路径指的是在该业务活动中产生了什么异常,或者产生错误等的处理

1.4转化为图形表示

采用UML的活动图,时序图对以上列出的用例表进行转化,使开发人员对系统由一个更加直观的认识。

这仅仅是我阅读该书的一点体会。详细的介绍参考《用例分析技术》一书!

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值