当前位置: 首页 > >

用例建模之用例图

发布时间:

用例图 UseCase Diagram


通俗来说,用例是文本形式的情节描述,用以说明某参与者使用系统以实现某些目标。用例建模主要是编写文本的活动,而非制图。



用例建模的制品有用例图和用例描述,我这篇博客只说下画用例图的一些方法和注意要点。但需要强调的是,用例是文本文档,用例图在编写用例工作中是次要的。
制作合理的用例图,通常给团队带来以下利益:


明确系统的业务范围、服务对象(角色)、外部系统与设备帮助识别技术风险,提前实施关键技术原型公关与学*易于评估项目工作量,合理规划迭代周期,规划人力需要

用例可以说是关键的需求输入,因此在画用例图前要进行需求识别:确定用例图涉及的系统,Actor,服务(用例)以及它们之间的关联。画图工具为Umlet,简洁起见,基础知识不再赘述,以下需求识别我只强调注意要点。


需求识别步骤
1. 确定研讨的系统

不要将系统的名称起的太空泛,明确业务,如“网上商店”可具体化为“网上书店”。


2. 识别 Actors

识别使用系统的主要参与者(primary actors)/角色(roles)
不要用“用户”代表系统使用者,以避免过于通用导致缺乏用户体验。例如,你的系统服务对象是程序员,但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同

识别系统依赖的外部系统
要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统,除了订单配送、支付、销售账单由其他专业系统完成外,房源管理都应由独立系统完成,以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一


3. 识别用例(服务)

识别用户级别用例(user goal level)
以主要参与者目标驱动,收集主要参与者的业务事件

识别子功能级别的用例(sub function level)


有些操作过于简单不足以成为一个用例,如:加入购物车有的操作可以成为一个用例,但不适合再对其划分子用例,如:排序可以单独成为一个用例,但是具体按什么标准排序不用成为新的子用例复杂业务分解。将业务分解为若干步,便于交互设计与迭代实现强调技术或业务创新。例如:“识别人脸”,尽管从用户角度是单步操作,但背后涉及技术解决方案是比较复杂的

正确使用用例与子用例之间的关系


<< include >> 表示子用例是父用例的一部分,通常强调离开这个特性,父用例无法达成目标或失去意义!<< extend >> 表示子用例是父用例的可选场景或技术特征。<< include >> 箭头指向子用例;<< extend >> 箭头指向父用例。箭头表示的依赖关系!
4. 建立 Actor 和 Use Cases 之间的关联

使用 无方向连线,表示两间之间是双向交互的协议


用例图实例

画用例图具体的条框很多,但如果不拿实例来说明,确实是纸上谈兵,很难真正理解以及应用。用例图很难有标准答案,下面是去哪儿订酒店在线服务系统的用例图,仅供参考。



友情链接: