UML 用例规约

AI权益加码!Claude Code、Cursor等20+工具免费用! 购周边限时加赠Coding Plan Lite,畅享主流AI工具!学习进阶更高效! 阅读详情

用例规约

  1. 用例图是骨架,而用例规约则是其内在的肉
  2. 用例文档的核心,而用例图作为用例文档的总图

 1.前置条件:把它们看做是看门人,它阻止参与者触发该用例直到满足所有条件(说明在用例触发之前什么必须为真)

 2.后置条件:对于有多个事件流的用例,则应该有多个后置条件(用例执行后什么必须为真)

 3.事件流描述要点:

 

              

 

    3.0 成功场景(正常事件流的描述)

                        扩展场景(备选事件流)
                          
 

3.1.只书写“可观测”的

 

3.2.使用主动语句 

 

3.3.句子必须以参与者或系统作为主语

 

3.4.不要涉及界面细节(下面是反例)

 

3.5.分支和循环 

 

 

 

用例规约文档参考模版

用例规约文档参考模板如下:(也可参考其他模板,红色表示必须填写的部分)

 

用例名称

处理销售

用例编号

POS001

执行者

收银员

用例简述

该用例规定了收银员如何利用系统进行销售过程的处理。

涉众及兴趣

收银员:希望能够准确、快速的输入,而且没有支付错误,因为收银员如果少收了钱,就要从他的薪水中扣除相应的金额。

顾客:希望购买过程能够省力,并得到快速的服务,希望得到购买证明,以便退货。

公司:希望准确地记录交易,并满足顾客的要求。希望保证支付授权服务的信息被记录。希望有一定的容错性,即使某些服务暂时不可用(如远程信用卡验证)也能允许收款。希望能够自动、快速的更新帐目和库存信息。

支付授权服务:希望按照正确的格式和协议收到数字授权的请求,希望准确计算给商店的应付款。

前置条件

收银员必须已经被正确识别和授权。

后置条件

存储销售信息,更新帐目和库存信息,生成收据,记录支付授权服务的许可。

基本流程

1.顾客携带购买的商品或服务达到POS机收费口。

2.收银员开始一次新的销售。

3.收银员输入商品标识。

4.系统记录单件商品,并显示该商品的描述、价格和累加值。价格可以根据一套定价规则来计算。收银员重复3-4步,直到结束。

5.系统显示总值。

6.收银员请顾客付款。

7.顾客支付,系统处理支付。

8.系统记录完整的销售信息,并将销售和付款信息发送到外部的记帐系统(进行记帐)和库存系统(更新库存)。

9.系统打印收据。

10.顾客带着商品和收据离开。

扩展流程

1a 任何时刻,发生以下状况,系统将失败:为了支持恢复操作和正确的记帐,要保证所有交易的敏感状态和事件都能够从场景中的任何一步中完全恢复。

1.收银员重启系统,登录,请求恢复上次状态。

2.系统重建之前的状态。

2a. 系统恢复过程中检测到异常:

1.系统向收银员指示错误,记录此错误,并进入一个清空状态。

2.收银员开始一次新的销售。

3a. 非法标识:

1.  系统指示错误并拒绝输入。

 

4a. 系统生成的商品价格不是顾客想要的价格(顾客抱怨太贵,要求减价):

1.收银员重写价格。

2.系统显示新的价格。

 5a. 顾客声称他们符合打折条件(例如:VIP顾客):

 1.收银员发出打折请求。

2.收银员输入顾客的个人身份信息。

3.系统按照打折条款给出折扣价值。

5c. 顾客要求使用信用卡结帐:

 1.收银员发出信用卡结帐的请求。

 2.收银员输入顾客的个人身份信息。

 3.系统从信用卡上扣除贷款。

6a. 顾客想用现金付款,但随身现金不足:

 1a. 顾客使用替代的支付手段。

1b. 顾客告诉收银员,他要取消此销售,收银员在系统上取消此销售。 7a.现金支付:

1.收银员输入收取的现金数额。

2.系统给出应找的金额,并弹出现金抽屉。

 3.收银员放入收取的现金,并拿出应找的余额给顾客。

 4.系统记录现金支付。

7b. 信用卡支付:

1.顾客输入信用卡帐号。

2.系统向外部的信用卡授权服务系统发送支付授权请求,并请求批准此支付。

非功能需求

1、使用大型平面显示器,交易过程中的信息要能够在1米之外看清楚。

2 90%的信用卡授权机构的响应应该在30秒内收到。

3、支持多种语言显示。

4、在步骤3和步骤7中可以插入新的业务规则。

业务规则

3a. 商品标识可以用条码扫描或键盘输入。

3b. 商品标识可以是各种不同的编码方式。

7a. 信用卡帐号信息可以使用读卡器或键盘输入。

7b. 记录在纸面收据上的信用卡支付签名。

发生频率

可能会持续发生。

设计约束

系统中断后的自动恢复问题,怎样保存先前的交易记录? 

 

 

 

 

 

系统用例规约编写步骤:
        1)用例编号

        2)用例名

        3)用例描述

        4)参与者

        5)前置条件

        6)后置条件

        7)基本路径

                (1)。。。

                (2)。。。

                (3)。。。

        8)扩展点

                (2)a。。。

                        (2)a-1。。。

        9)特殊需求

        9)补充说明

 

 

文档(用例规)包含步骤或要素 例规是描述系统功能需求的核心文档,主要包含7个要素:1)动词+名词命名的用名称;2)简要业务描述;3)输入/输出的数据流;4)性能、安全等非功能性需求;5)可验证的前置/后置条件;6)包含备选流和异常处理的扩展性;7)开发优先级标识。典型用例规应包含名称、描述、条件、事件流等核心内容,考试中尤其重视基本流和备选流的描述。数据流和非功能性需求视题目要求补充,优先级在敏捷开发中更为重要。 阅读详情

相关推荐

UML例规实战指南:从需求到代码的精准契

在软件工程领域,需求分析是确保项目成功的关键环节。传统的UML图擅长描述系统边界和功能概览,但无法承载详细的业务规则和交互流程,这常常导致开发、测试与产品团队之间的理解偏差。为了解决这一问题,用例规应运而生,它作为一种结构化的需求描述方法,将模糊的功能点转化为可执行、可验证的规格说明。其核心价值在于建立团队共识,成为后续系统设计、开发和测试的共同基准,有效减少返工和歧义。通过定义清晰的前置/后置条件、主事件流、扩展事件流以及业务规则,用例规将需求从概念层面落地为具体束。在实践层面,它直接驱动领域建

weixin_26767391的博客 319

业务用例规模版(详细版)

此模板给出了用例规中需要书写的各项,内容详尽,希望能给您已借鉴。

UML例规实战指南:从需求分析到开发落地的结构化方法

在软件工程的需求分析阶段,用图常被用作描述系统功能的可视化工具,它勾勒了参与者与系统之间的交互概览。然而,仅凭用图往往难以清晰定义具体的交互细节和业务规则,这正是需求传递中产生歧义的关键所在。其核心原理在于,需求分析需要从静态的结构描述,深入到动态的行为规约,以确保所有干系人对‘做什么’达成一致。这一过程的技术价值在于,它能显著减少开发过程中的沟通成本、返工和缺陷,提升软件交付质量。在实际应用场景中,尤其在电商、金融等业务逻辑复杂的领域,明确的需求规约是保障项目顺利推进的基石。本文聚焦于**用例规**

weixin_42548874的博客 320

用Rational RequisitePro写用例规(Use Case Specification)的心得

用Rational RequisitePro写用例规(Use Case Specification)的心得

UML】第7篇 用图(2/3)

UML中的用,命名、识别、规约、用识别常见错误。别看简单,你真的很清晰吗?

AI人人懂 3990

例规的写法、常见用例规、核心业务用例规

.

代码是程序员的语言,博客是思想的桥梁,连接你我,共享智慧之光。 4万+

UML例规

例规要素包括:用名称、参与者、用编号、简单描述、前置条件、主要事件流、次要事件流(可能会出现的一些外)、后置条件...

weixin_65384007的博客 2874

UML2用描述以及需求用例规文档生成

初学UML者,应该避免这样一种误解――认为就是由参与者和用构成的用图就是用模型,用图只是在总体上大致描述了系统所能提供的各种服务,让我们对于系统的功能有一个总体的认识。但用图并非如此,在用图中我们还需要针对每一个用描述它的详细信息,这些信息包含在用例规中,因此用模型应该是由用图和每一个用的详细描述――用例规所组成的。每一个用的用例规都应该包含以下内容: l

企业级UML2建模工具、MDA工具、数据库建模工具、需求管理工具、集成开发平台 1586

5-用模型测试

A. 用编号B. 用简述C. 参与者D. 用名称我的答案:B正确答案:B用例规1.0分A. 对B. 错我的答案:错正确答案:错用例规1.0分。

代码欢乐豆 1279

UML建模(六)需求之系统用例规

image.png 1.用例规的内容 用例规就是以用为核心来组织需求内容的需求规约通过前置条件(precondition)、后置条件(postcondition)以契的形式表达需求 前置条件:用开始前,系统需要满足的束。后置条件:用成功结束后,系统需要满足的束。 前置条件、后置条件必须是系统能检测的。 前置条件必须是用开始前系统能检测到的。 前置后置条件是状态...

小武的Blog 6637

UML分析与用例规表:以聊天室软件为

分析是UML中用于捕获系统功能需求的一种方法。它从用户的角度出发,描述用户(参与者)与系统之间的交互行为,从而明确系统应该具备哪些功能。在需求分析中,用分析起到了至关重要的作用,它帮助我们梳理出了系统的各个功能模块以及用户与这些模块之间的关系。

weixin_73924918的博客 1581

统一建模语言UML轻松入门之用

 目前,在的内地版《神雕侠侣》中,杨过和小龙女有一份不为人知的默契与浪漫,那就是他们所绘制的并肩小人图。这样的小人图,是UML图的一部分,被称为参与者。  2.1 用与用图  用是需求分析中最重要的概念,需求表征了一个系统的设计特性、特征和行为,描述一个系统的需求意味着描述了建立在该系统外部的事物与系统之间的契,契上声明了期望系统做什么。  需求获取(Requirement Elic

290

例规

初学UML者,应该避免这样一种误解――认为就是由参与者和用构成的用图就是用模型,用图只是在总体上大致描述了系统所能提供的各种服务, 让我们对于系统的功能有一个总体的认识。但用图并非如此,在用图中我们还需要针对每一个用描述它的详细信息,这些信息包含在用例规中,因此用模 型应该是由用图和每一个用的详细描述――用例规所组成的。每一个用的用例规都应该包含以下内容: l 简

u013223565的专栏 1万+

统一建模语言UML轻松入门(2)――静态建模:用

目前,在热播的内地版《神雕侠侣》中,杨过和小龙女有一份不为人知的默契与浪漫,那就是他们所绘制的并肩小人图。这样的小人图,是UML图的一部分,被称为参与者。2.1 用与用图用是需求分析中最重要的概念,需求表征了一个系统的设计特性、特征和行为,描述一个系统的需求意味着描述了建立在该系统外部的事物与系统之间的契,契上声明了期望系统做什么。需求获取(Requirement Elicitation) 是需求工程的主体,其主要工作是建立待开发系统的模型,而用就是用于建立这种模型的良好方法。用最初由Iv

一杯茶品人生沉浮,平常心造万千世界 1213

绘制qq群的基础用图_软件项目实训及课程设计指导——用事件流和用例规的描述示...

软件项目实训及课程设计指导——UML事件流和用例规的描述示1.1.1 用事件流和用例规1、UML中的用模型方法所存在的主要问题(1)采用用图对软件系统需求的描述是不全面的由于用图仅能描述软件系统中的功能性的需求,而不适合描述非功能性的需求和设计束等方面的信息;另外,用图也不能描述出软件系统中的每个用所对应的业务流的实现过程等方面的信息。下图所示为某个BBS论坛系统的后台管理...

weixin_39940182的博客 764

软件工程各阶段的UML

转载请注明原文地址:http://www.cnblogs.com/ygj0930/p/6616876.html UML是统一建模语言,主要用于软件的分析与设计阶段。但是UML有这么多图,具体怎么用呢? 一:需求分析阶段的业务用图 用图,是用来表示 系统角色 与 系统什么功能 发生交互的图。通过用图,可以很清晰地表示系统放主要功能。用图在我们进行软件...

a631278993的博客 3044

如何在用之间传递值_软件项目实训及课程设计指导——用事件流和用例规的描述示...

软件项目实训及课程设计指导——UML事件流和用例规的描述示1.1.1 用事件流和用例规1、UML中的用模型方法所存在的主要问题(1)采用用图对软件系统需求的描述是不全面的由于用图仅能描述软件系统中的功能性的需求,而不适合描述非功能性的需求和设计束等方面的信息;另外,用图也不能描述出软件系统中的每个用所对应的业务流的实现过程等方面的信息。下图所示为某个BBS论坛系统的后台管理...

weixin_39842955的博客 1938
上一篇: 结构模型视图
下一篇: UML 几种动态图的用法
工人
博客等级 码龄15年 36粉丝 88原创
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值