如果用例A与用例B相似,但A的功能较B多,A的动作序列是通过在B的动作序列中的某些执行点上插入附加的动作序列而构成的,则称()A.用例A扩展用例BB.用例A包含用例BC.用例A继承用例BD.用例A实现用例B

正确答案：D
解析：用例(use case)用来描述系统在对事件做出响应时所采取的行动，即它确定了一个与系统参与者进行交互，并由系统执行的动作序列。可见，一个用例本身并不是一个功能需求，它代表了系统的一个单一的目标，是一个行为上相关的步骤序列。选项D所描述的范围太广，不够准确。在UML规范中，参与者是指系统所涉及到的人，或者是用户在本系统中扮演的角色。一个参与者总是在系统的自动化边界之外。

参考答案：A

正确答案：D

正确答案：D

正确答案：D
解析：用例(usecase)用来描述系统在对事件做出响应时所采取的行动，即它确定了一个与系统参与者进行交互、并由系统执行的动作序列。可见，一个用例本身并不是一个功能需求，它代表了系统的一个单一的目标，是一个行为上相关的步骤序列。本试题选项D所描述的范围太广，不够准确。在UML规范中，参与者是指系统所涉及到的人，或者是用户在本系统中扮演的角色。一个参与者总是在系统的自动化边界之外。解答此类试题的一般思路是理解用例的基本概念。

答案：×

正确答案：用例分析技术是Rational三友之一的Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究并于1986年总结、发布的一项源于实践的需求分析技术。 Ivar先生在加盟Rational之后与三友合作提出了UMI、完善了RUP用例分析技术也因此被人广泛了解和关注。 用例分析技术为软件需求规格化提供了一个基本的元素而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是开发团队与客户之间有效的沟通工具它可以用来描述功能和非功能需求其有助于确保需求的可跟踪性能够抑制过早的设计。不过值得注意的是关于用例有2个常见的误区。 (1)用例分析技术包括了整个需求过程：它只是一个需求分析技术是在传统的需求捕获技术的基础上使用的无法替代这些技术； (2)用例分析技术是分解技术：其实用例分析技术是一种合成技术将在需求捕获中收集而来的零散的特性合成为用例。 因此要清楚地认识用例源于涉众不能够自己杜撰出用例但也不要企图直接问他们还有什么用例；另外用例描述的编写工作应由开发人员和客户组成的团队完成。 总之用例来源于传统的需求捕获方法所产生的结果。通常采用迭代的方式来创建需求：首先生成提纲和高层描述(即粗略的用例模型)然后对其进行拓展和深化(即对用例模型的描述进行完善)最后进行集中的整理与修剪。用例模型的建立过程主要分为识别参与者(actor)、合并需求获得用例、细化用例描述3个步骤。 根据上面的分析可知用例是一种需求的描述方法因此用例的获取也是需求的获取因此在本篇论文的写作过程中应该充分说明如何结合用例技术来获取需求。 具体来说写作要点主要包括以下几个方面： (1)所列举的参与分析和开发的软件项目应该适合于用例分析技术而非如驱动程序之类系统参与者不明显或不重要的应用。 (2)文章中应该详细地说明获取系统用例所采用的工作步骤应该从需求的捕获开始然后详细地说明如何识别参与者如何识别用例如何进行描述的细化和模型的建立。 用例获取的基本步骤： ①定义该应用系统的边界(可以用计算机系统作为边界也可以用使用该应用系统的机构中的部门界限作为边界还可以用该机构本身作为边界)。 ②识别出该应用系统所有的参与者。 ③对于所识别出的每一个参与者分别确定； .该参与者所参与的每一种业务活动； .各种业务活动的完整的事件序列； .激发上述每一个事件序列的参与者。 ④对③中确定的事件序列进行分析去掉其中重复的事件序列。 ⑤用结构化的自然语言来描述④中确定的每一个事件序列得到初步确定的每一个用例。 ⑥对⑤中初步确定的每一个用例进行分析和必要的重组采用包含(include)、扩展 (extend)和概括(generalization)关系来表示用例之间的关系最终得到所有的用例。 (3)在描述获取系统用例的步骤时应该尽可能结合项目实际情况描述具体的过程而不要过多地列举相关书籍中内容干巴巴的理论会显得文章十分空洞要充分体现出真实性。 (4)可以充分地引入一些用例分析模式来说明用例的获取过程。 (5)文章中应该对用例获取的效果进行分析特别是对用例模型的全面性并且应该充分体现出客户在用例获取过程中的参与情况。 (6)可以适当地对用例获取的过程中的不足进行评价并提出相应的改进方法。
用例分析技术是Rational三友之一的Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。 Ivar先生在加盟Rational之后，与三友合作提出了UMI、完善了RUP，用例分析技术也因此被人广泛了解和关注。 用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是开发团队与客户之间有效的沟通工具，它可以用来描述功能和非功能需求，其有助于确保需求的可跟踪性，能够抑制过早的设计。不过值得注意的是，关于用例有2个常见的误区。 (1)用例分析技术包括了整个需求过程：它只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，无法替代这些技术； (2)用例分析技术是分解技术：其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例。 因此，要清楚地认识用例源于涉众，不能够自己杜撰出用例，但也不要企图直接问他们还有什么用例；另外用例描述的编写工作，应由开发人员和客户组成的团队完成。 总之，用例来源于传统的需求捕获方法所产生的结果。通常采用迭代的方式来创建需求：首先生成提纲和高层描述(即粗略的用例模型)，然后对其进行拓展和深化(即对用例模型的描述进行完善)，最后进行集中的整理与修剪。用例模型的建立过程主要分为识别参与者(actor)、合并需求获得用例、细化用例描述3个步骤。 根据上面的分析，可知用例是一种需求的描述方法，因此用例的获取也是需求的获取，因此在本篇论文的写作过程中，应该充分说明如何结合用例技术来获取需求。 具体来说，写作要点主要包括以下几个方面： (1)所列举的参与分析和开发的软件项目应该适合于用例分析技术，而非如驱动程序之类，系统参与者不明显或不重要的应用。 (2)文章中应该详细地说明获取系统用例所采用的工作步骤，应该从需求的捕获开始，然后详细地说明如何识别参与者，如何识别用例，如何进行描述的细化和模型的建立。 用例获取的基本步骤： ①定义该应用系统的边界(可以用计算机系统作为边界，也可以用使用该应用系统的机构中的部门界限作为边界，还可以用该机构本身作为边界)。 ②识别出该应用系统所有的参与者。 ③对于所识别出的每一个参与者，分别确定； .该参与者所参与的每一种业务活动； .各种业务活动的完整的事件序列； .激发上述每一个事件序列的参与者。 ④对③中确定的事件序列进行分析，去掉其中重复的事件序列。 ⑤用结构化的自然语言来描述④中确定的每一个事件序列，得到初步确定的每一个用例。 ⑥对⑤中初步确定的每一个用例进行分析和必要的重组，采用包含(include)、扩展 (extend)和概括(generalization)关系来表示用例之间的关系，最终得到所有的用例。 (3)在描述获取系统用例的步骤时，应该尽可能结合项目实际情况，描述具体的过程，而不要过多地列举相关书籍中内容，干巴巴的理论会显得文章十分空洞，要充分体现出真实性。 (4)可以充分地引入一些用例分析模式来说明用例的获取过程。 (5)文章中应该对用例获取的效果进行分析，特别是对用例模型的全面性，并且应该充分体现出客户在用例获取过程中的参与情况。 (6)可以适当地对用例获取的过程中的不足进行评价，并提出相应的改进方法。