一.系统边界和参与者
参与者Actor定义:在系统之外,透过系统边界和系统进行有意义的交互的任何事物
透露出参与者的特征:
1.不属于系统
2.通过系统边界直接和系统交互->参与者的确定决定了系统边界的确定
3.进行有意义的交互
4.任何事物
其中第二点的"直接"要注意:如果一个顾客通过售票员买机票,那么对于售票系统来说,售票员是参与者而顾客不是.
由此又产生了业务建模和系统建模的区别:对于售票系统来说,当业务建模的时候,我们描述的是顾客来订票,可能还有票务中心的主任来询问售票情况等等事件.但是系统建模的时候,他们都不是我们的对象,我们描述为售票员要售票和提供售票情况的事件的描述,因此这两者在建模的不同阶段是不一样的.
在有些自动系统中,时间往往是触发系统工作的外部事物,因此参与者是时间,不可忽略.
识别参与者方法:面对一个系统时,你应该问这些问题:
谁使用系统?
谁改变系统数据?
谁从系统获取信息?
谁需要系统的支持来完成日常工作?
谁负责管理并维护系统正常运行?
系统要应付那些硬设备?
系统要和其他的系统交互吗?
谁对系统产生的结果感兴趣?
时间,气候等外部条件呢?
当你回答完这些问题之后,你的答案基本上就涵盖了参与者的候选人.
识别参与者的重要性:
1.根据参与者识别系统用例:因此为了完整系统的功能,你识别的系统参与者宁多勿少.
2.测试部署阶段你可能会通过识别者的角度去了解系统的完整性.
3.用例文档编写阶段,参与者不是很重要,但是你应该考虑参与者的泛化关系,避免出现用例的重复功能.
二.识别事件
罗列清楚系统事件,是正确建立系统用例的必要条件.
系统事件分为两类:系统外部事件和系统内部事件
外部事件就是外部参与者对系统交互的具体工作,内部事件就是系统内部触发的工作,通常由时间触发.
识别事件的方法:头脑风暴法-主语+谓语+宾语,描述系统可能发生的事情,尽可能全面,同样是宁多勿少的原则,不过你可以根据事件的重要程度进行一个排序,这能加深你对系统的认识.
通常把识别出来的事件列成一个表格:称为3A表
Actor Action Aim
参与者 作甚么 业务目的
... ... ...
三.识别用例
用例定义:用例是一组用例实例
用例实例定义:系统执行的一系列动作,用以产生参与者可观测到的结果值
用例要点:
1.位于系统 --必须由系统运行
2.目标导向 --用例运行必须有所目的
3.止于边界 --可以观测到结果,并且是在边界和外部有所交互的
4.用户观点 --参与者观测
5.粒度 --是一组有共同目标或者可以类聚的目标的实例们组成
识别用例是从业务建模开始的,也就是说我们描述用例是从用户的角度即用户观点出发的识别行为,描述用例是用纯粹的业务语言,而不是技术语言.比如描述为清缴税款,而不是J2ee架构.因此,用户的命名也是从用户的角度出发,描述用户要做的一件通过系统完成有目的,有结果的行为.
用例的粒度不宜过细,过细的分解会导致用例描述的错误:
1.把交互的步骤成为一个用例,而不是把一类一系列步骤作为一个用例.例如,用户登陆是一个用例,错误的做法是把请求输入用户名也作为一个用例.
2.把必要的处理过程中的一些系统内部活动称作用例:验证用户,连接数据库,发送SQL请求等称作一个用例,其实都是用户登陆这一次交互的步骤而已.
3.把识别用例的工作当成是关系数据库分析的工作:称作四轮马车的错误,即CRUD(Create Read Update Delete).例如管理用户是一个用例,但是可能变成了增加用户,查询用户,修改用户,删除用户的"系统就是数据的增删改查"的认识论错误.
识别用例的一个关键性原则就是:站在用户的角度分析用户的目的,而不是站在系统的角度,更不是站在数据的角度.
通过建立的系统事件可以很顺利的画出用例图,但是应该记住"用例的本质是文字",所以我们最终要将用例图转化成用例文档.可以用下面的例子格式书写用例文档:
用例编号:
用例名:
用例描述:
参与者:
前置条件:开始该用例时的所必需的系统和环境状态
后置条件:结束该用例时的所具备的系统和环境状态
基本路径:
1…..××××
2……××××
3…..××××
扩展点:
2a.××××
2a1….×××××
补充说明:
前置条件和后置条件可以反应用例间的相互依赖关系.还可以防止漏掉某些用例
用例之间的关系:扩展extends,包含include,泛化
