UML核心元素(四)——用例
-
定义了一组用例实例,其中每个实例都是系统所执行的一系列操作,这些操作生成特定主角可以观测的值。(定义系统范围、获取功能性需求)
-
一个场景就是一个用例的实例
-
一个完整的用例由参与者,前置条件,场景,后置条件构成。
-
用例的特征
-
用例是相对独立的:不能达到参与者的完整愿望不能称为用例。
-
用例的执行结果对参与者是可观测和有意义的(PS:如一个后台进程监控参与者在系统里的操作,并在参与者删除数据之前执行备份操作。虽然他是系统的一个必须组成部分,但它在需求阶段却不应该做为用例出现。因为这是一个后台进程,对参与者来说是不可观测的,它应该作为系统需求在补充规约中定义而不是一个用户需求)
-
事情必须由参与者发起,不存在没有参与者的用例,用例不应该自动启动,也不应该主动启动另一个用例。
-
用例必须由动宾短语形式出现。
-
一个用例就是一个需求单元,分析单元,设计单元,开发单元,测试单元,甚至部署单元。
-
用例和功能的误区
-
功能是计算机术语,用来描述计算机的而非定义需求的术语。
-
功能实际描述的是输入-计算-输出,典型的面向过程分析模式,因此把用例当作功能点的做法实际是在做面向过程的分析。
-
本质上来说功能和用例完全不同。
-
事物是什么(结构性观点,即客观存在)?事物能做什么(功能性观点,事物的可利用价值,不能够说明事物在某种情形下的真正价值,也就是缺乏上下文环境)?人们能够用这个事物做什么(使用者观点,说明事物对于使用者的意义)?
-
对于还不存在的事物,如软件,不能从结构观点去描述,也不能从功能观点去描述。
-
总结
-
功能是脱离使用者的愿望而存在的。
-
供能是孤立的,给一个输入,通过计算就有一个固定的输出,只要按下开关灯就亮。用例是系统性的,描述谁在什么情况下通过什么方式开灯结果是什么。
-
如果非要从功能的角度解释用例,用例可理解为一系列“功能”的组合。UML没有功能这个词。
-
业务用例
-
专门用于需求阶段的业务建模
-
业务范围不等于需求,软件需求真正的来源是系统范围,也就是系统模型,业务模型是系统模型的最重要输入。
-
不再计算机中实现的业务就可以不进入系统范围,也就是可以不把它作为一个需求。
-
业务用例实现
-
用于需求阶段的业务建模,为业务领域建立模型采用这种版型。
-
就是一个业务用例的实现,一个用例可以有多种实现方式。
-
用例实现是联系模型和系统实现之间的桥梁。
-
用例粒度
-
业务建模阶段:每个用例能够说明一件完整的事情为宜,即一个用例可以描述一项完整的业务流程。
-
概念建模阶段:每个用例能描述一个完整的事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。
-
系统建模阶段:能够描述操作者与计算机的一次完整交互为宜。(在RUP中,项目计划要依据系统模型编写,因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。一个系统的业务用例定义在10到50个之间,总体原则是同一个需求阶段,所有的用例的粒度应该是同一个量级。)
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 推荐几款开源且免费的 .NET MAUI 组件库
· 实操Deepseek接入个人知识库
· 易语言 —— 开山篇
· Trae初体验