参与者(Actor):表示的是一个系统用户,也就是与应用程序进行交互的用户、组织或者外部系统。
用例(Use Case):表示的是对系统提供的功能、服务的一种描述。
用例之间的关系:
包含关系(Include):表示用例可以简单地包含其他用例所具有的行为,并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示,箭头指向被包含的用例。泛化关系(Generalization):泛化指的是一个父用例可以被特化形成多个子用例,而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示,箭头指向父用例。关联关系(Association):表示的是参与者与用例之间的关系。在UML中常用一条直线,或者是一条带箭头的线条来表示,箭头指向信息接收方。扩展/延伸关系(Extend):表示在一定条件下,把新的行为加入到已有的用例中,获得的新用例叫做扩展用例,原有的用例叫做基础用例,相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示,箭头指向基础用例。确定研讨的系统:使用用例图 System框 表示一个待研究的系统。正确命名系统或子系统
识别 Actors :
识别使用系统的主要参与者(primary actors)/角色(roles) 。使用用例图 actor符号 表示,通常放在系统的左边识别系统依赖的外部系统 :使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备,并使用构造型(Stereotype)识别识别用例 :
识别用户级别用例(user goal level) 以主要参与者目标驱动,收集主要参与者的业务事件manage 用例。特指管理一些事物的 CRUD 操作,例如管理文件、管理用户等识别子功能级别的用例,实现业务复用,复杂业务分解正确使用用例与子用例之间的关系,如include和extend建立 Actor 和 Use Cases 之间的关联 :使用 无方向连线,表示两间之间是双向交互的协议
对于利益相关人:
可以直观看到系统的结果和用户的功能体验,保证系统按照用户的需求进行设计。用例能够根据需要对复杂程度和形式化程序进行增减调节,即能够响应用户(利益相关人)提出的需求,而用例图则使得这种调节更加便利,可以通过修改图形间的关系实现。对于开发者来说:
用例图是设计者设计过程的结论与参考,设计者与开发者之间的交流工具,开发者开发过程的蓝图。用例图使得开发者能够更明确地获得需求,更好地理解需求。用例图可以指导开发和测试,同时可以在整个过程中对其他工作流起到指导作用。选择2-3个你熟悉的类似业务的在线服务系统(或移动 APP),如定旅馆(携程、去哪儿等)、定电影票、背单词APP等,分别绘制它们用例图。并满足以下要求:
请使用用户的视角,描述用户目标或系统提供的服务粒度达到子用例级别,并用 include 和 exclude 关联它们请用色彩标注出你认为创新(区别于竞争对手的)用例或子用例尽可能识别外部系统和服务电影订票系统 背单词系统
然后,回答下列问题:
为什么相似系统的用例图是相似的? 答:相似系统面对的参与者和用例是相似的,用例之间的关系也是同构的。用户预期的功能都是相似的,即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。
如果是定旅馆业务,请对比 Asg_RH 用例图,简述如何利用不同时代、不同地区产品的用例图,展现、突出创新业务和技术? 答:首先可以先画出并查看旧时代的,多个地区相同产品的用例图,然后可以从中找出不足的地方,加以改进,例如删掉一些冗余的功能,进行市场调研看下这些旧产品有什么用户期望的功能缺失,可以进行补充创新,或者说结合当前时代的技术新特点,像室内定位,区块链等新技术,对原有的业务功能进行创新。
如何利用用例图定位创新思路(业务创新、或技术创新、或商业模式创新)在系统中的作用 答:项目早期对用例图进行分析,通过横向对比其他同类产品的用例图,可以很直观地发现当前市场上此类产品的一般设计模式。同时,我们也可以对产品设计的不足和用户的痛点一目了然,我们针对用例图上某方面存在的不足,提出比较合理的解决方案,将其作为我们产品的创新点,作为我们的主要竞争力。
请使用 SCRUM 方法,选择一个用例图,编制某定旅馆开发的需求(backlog)开发计划表
根据任务4,参考 使用用例点估算软件成本,给出项目用例点的估算