《软件方法》第六章自测题

最新推荐文章于 2023-12-04 16:36:59 发布

矜独

最新推荐文章于 2023-12-04 16:36:59 发布

阅读量1.1k

点赞数 3

分类专栏： UMLChina软件方法各章练习自测文章标签： uml 软件开发

本文链接：https://blog.csdn.net/qq_48297353/article/details/121037195

版权

UMLChina软件方法各章练习自测专栏收录该内容

8 篇文章 8 订阅

订阅专栏

本文是作者作为大三学生整理的UMLChina《软件方法》第六章用例规约的学习笔记，涵盖了用例规约的各个要素，如涉众利益、路径步骤、前置后置条件、扩展路径和补充约束等，并提供了相关自测题和解答，旨在帮助读者深入理解和应用用例建模。

摘要由CSDN通过智能技术生成

关于UMLChina

前言

笔者为在校大三生，初次接触UML建模语言，在学习《软件方法》一书时整理UMLChina上《软件方法》各章练习题自测及《软件方法》建模竞赛题分卷自测以供日后学习参考，特此整理于CSDN博客以供各位学习，并附上UMLChina网址链接 UMLChina链接，如若文章出现错误，请及时联系作者进行批评指正。

温习回顾

在做本章测试前，我们先一起回顾一下本章可能涉及的知识点：

1. 用例规约
在建模工作流中，我们所指的需求通常分为三类，它们分别是：功能需求，质量需求，设计约束。他们都在用例规约中具有相应的对应描述，如功能需求对应用例、路径、步骤、字段列表、业务规则，质量需求对应质量需求，设计约束对应设计约束。

在描述用例规约时，我们可以采用线性式和表格式对其进行描述，下图是两种形式的区分和样式：
在这里插入图片描述
作者推荐的三款用例规约工具分别是：casecomplete,ENTERPRISE ARCHITECT,Visual Paradigm（笔者使用的是Enterprise Architect）

前置条件：用例开始前，系统需要满足的约束；
后置条件：用力结束后，系统需要满足的约束；
在形式上，它们都必须可以被系统所检测（如：秘书将资料整理完毕不能被系统检测，因此不能作为前置条件使用），在内容上，如果缺失条件会造成对涉众利益的影响（如：系统已保存论文全部信息未设置为前置条件，则有可能造成论文信息遗失进而影响学生及内审专家等涉众的利益）。这里还需要注意：登录过程会频繁出现在各执行者的多项操作中，我们认为它包含在其他用例中，不单独列为系统用例。

涉众利益：在理解这个概念前，我们先举个形象的例子来理解什么是涉众：假设我们将设计后执行者与系统交互的整个流程当作是台上的演出者，那涉众就好比台下的观众，台上的一举一动都牵动着台下观众的心弦（影响着利益），即涉众利益，可以形象的比喻为演员和观众。

在《软件方法》一书中，我们常指的涉众，包括：人类执行者，上游，下游，信息所代表的人等等，他们间相互的利益关系存在着微妙的动态平衡。这时，业务建模的重要性就凸显而出了，当业务建模对整个业务体系完善充足后，软件设计者则可以根据序列图清晰的分析业务中所涉及的涉众关系，这个作用我们通常称为——识别涉众

对于涉众利益的清晰规划，我们可以简单将其理解为“不变”与“易变”的区分，举个例子：对于涉众储户而言，储户的储值金额，存储时间等一系列“易变"因素显然不能被描述为涉众利益，但是储户所希望的时间上的便捷，对权益受损的担忧，都是“不变”的利益需求，因此，我们设定这种意义上的“不变”为涉众利益。套用书中的原话——涉众利益是可以积累的财富。

路径步骤的初衷——凸现用例核心价值的路径。因此在写路径时，应尽可能避免废话连篇的赘述。那么怎么写路径呢？我们记住两个要点：一个是主执行者，一个是系统，路径的步骤就是主执行者与系统间不断交互的过程：在这里插入图片描述
像图中所示，主执行者向系统发送请求，系统向自身经过验证、改变，最后向主执行者做出回应，按照这样的流程设计路径步骤，往往不会出现错误。

图中的回合一及回合二便是一个典型的路径步骤案例，这里我们可以发现，系统内部的验证和改变并不一定是在所有的步骤路径中都要体现的，但请求和回应一定是必要的！

路径步骤的几个要点：
1、使用主动语句——理清责任，谁是主责？（如：梅西传球，C罗射门，而不是梅西传球给C罗射门）
2、区分执行者和系统（例如：会员提交订单信息，系统保存订单，而不是会员保存订单）
3、主语只能是执行者名称和“系统”
4、使用核心域词汇（说人话，如下图演示）在这里插入图片描述 5、不要涉及界面组件和交互
6、不要写系统不能负责的事情（如：经理审查支票，应改为经理在系统确认支票已通过审查）
7、对于辅助执行者，我们应该称A请求B做某事，而不是直接写A做某事，如：系统将案件信息发送给AFIS系统进行查找—>改为系统请求AFIS系统比对

对于不同级别的需求，往往其精度与稳定性呈反比

可用性需求与交互设计的区别：这里需要注意一个重要事项——不同岗位不要高估自己的能力，如下图：
在这里插入图片描述
扩展路径：系统要处理的意外和分支（注意，必须要是系统能感知和要处理的）同时，扩展并不等于给出选项，我们要看交互行为的变化，扩展更不是链接，因为我们不能穷尽所有的可能组合。

关于补充约束，书中及PPT上有大幅概念描述，这里只提及几点：补充约束有字段列表、业务规则、质量需求、设计约束四个概念，字段列表通常对系统或执行者反馈的数据信息进行详细的描述；业务规则是核心域规则；质量需求是可用性、可靠性、性能、可支持性的描述，是对事物的度量；设计约束必须来自涉众，明白什么是涉众可以理解和验证的！

用例规约的精简原则：
1、涉众利益不能省
2、路径步骤和前置后置可省其一
3、交互类似的用例、写一个作为样例即可
4、非关键用例、可以不写用例规约

用例关系：用于整理用例规约
扩展《extend》：分离扩展路径
包含《include》：提取公共步骤集合
泛化：扩展的变体（一般不用）

最后，用例没有顺序！！！！！！！！！！！！！！！