第4章需求获取.ppt

1、第四章需求获得，4.1软件需求的初期表示4.2需求获得的过程模型4.3定义软件问题4.4框架例子4.5精化例子4.6审查例子模型，2020/7/31， 1，1，第四章需求获得，目的相关人员对目的软件系统的需求完全收集、整理，并以易于理解的业务语言形成描述这些文档的意义需求获得是需求工程中后续活动的基础， 需求工程是后续软件开发活动的基础需求获得对软件项目的成败有决定性影响的主要完成者是来自软件开发者的需求工程师其他参与者是来自委托者或者投资者的顾客是来自使用者的用户项目软件经理和质量保证工程师，2020/7/31 2、2需求获得活动的输入产品包括项目目标、范围和价值的概要文件项目合同或任务书经

2、审核合格的此次需求工程反复工作订单。 其输出产品：描述软件需求的初步需求模型。 该模型经需求分析演化为正式需求模型，是需求规约的主要组成部分。2020/7/31、3、4.1初始显示软件要求，本节介绍软件要求的使用示例和使用示例的初始显示。 需求捕获过程中使用的UML图形机制主要包括用例图、类图和活动图。2020/7/31、4、4.1.1用例、(1)用例的概念从外部用户的角度来看是参与者(actor )和目标软件系统之间的典型交互，其效果是参与者在软件系统的帮助下完成了业务功能吗可替代地，从软件系统内部的角度来看，使用代表系统执行的一系列操作，并且执行操作的结果是外部参与者感知到的。 2020/

3、7/31，5，5，使用案例。 如果多个用户在使用目标软件系统时扮演相同的角色，则这些用户将由单个参与者表示。 如果一个用户扮演多个角色，则同一个用户必须由多个参与者表示。 参与者可以是用户的类型，也可以是其他软件系统或物理设备。 2020年7月31日， 6、参与者也称为执行者(教材中使用的术语)，外部参加者是在与外部用户或外部实体交互的过程中发挥作用，与软件系统交换信息(利用本系统的功能)，在用例、例如课程登记管理系统中主要的参加者是“Registrar “Student”(学生)、“Teacher”(任意教师)“Billing System”(收费系统)已经实用化。 例如，如果需要在每学期的

4、第一个星期天自动启动摘要课程用例，则该用例的参与者必须是计时器。2020/7/31，7，7、用例、相对独立性和完整性是用例所需要的两个特征，用例展示了参与者结合目标软件系统实现相对独立、完整的业务目标的能力。 为了清楚地说明这种外部可见性功能，该用例通常进一步表现为参与者与软件系统之间的交互序列。 对于参与者来说，这些交互作用的目的或效果是实现业务目标对于开发软件系统来说，交互作用的过程就是使用此外部可见性功能的过程。 例如，授课登记管理系统的用例有教务管理者使用的制作授课表用例、教务管理者、学生和教师使用的查询授课表和授课信息用例、学生使用的制作授课修订画用例、教师使用的查询授课学生信息用例

5、2020/7/31，8，8，例句，(2)例句和软件需求的关系从例句的定义中容易理解，例句是功能性软件需求的主体部分。 在用例主导的需求工程中，用例描述占需求获得结果文件的大部分。 全球业务规则和大多数非功能性软件要求都不适合用例描述。有些业务规则仅影响单个或少数用例，您可以直接在用例说明中查看它们。 对于仅限制单个或少数用例的非功能性需求，也在用例说明中列出。 所谓2020/7/31,9、9、9、用例，(3)帧用例帧用例是指宏功能大致明确但内容不完全的用例。 引入框架用例的概念是为了满足需求获得过程中细节不完全确定的用例需求。 2020/7/31、10、4.1.2用例图和UML的用例模型代表从

6、软件系统的外部用户的角度看的每个系统功能，它代表软件系统的边界点，即在用例图中所有用例的集合作为目标2020/7/31，11，图4.1课程注册管理系统的用例图，2020/7/31，12，(1)参加者和用例之间的关系，参加者和用例之间的关系在用例图上表示为它们之间的连接边，其意义是用例的执行参与者和用例之间的连接边通常是无向边。 只有当多个参与者连接到用例时，才会考虑采用有向边，以强调其中一个参与者是该用例的主要参与者。 在这种有向边上，信息传播仍然可能是双向的。 参加者必须提供启动用例的初始信息，用例的执行结果也可以反馈给参加者。 要强调被动参与者仅从用例中获取信息，而不向用例提供信息，可以在

7、用例到被动参与者之间使有向边连续。 (2)用例间的关系、用例间的关系主要有包含、扩展、继承这3种。 包含关系：如果b是a的子功能并且建模器正确知道何时调用对应于a的操作序列b，则用例a包括用例b。 包含关系通常用于提取多个用例中共同的子功能项，以避免重复和冗馀。 例如，在课程登记管理系统中，在“摘要课程”以外的用例中需要用户的认证，将该子功能表现为“用户认证”用例，能够在原来的用例和该用例之间建立包含关系(参照图4.1 )。 2020/7/31，14，扩展关系结果a和b相似，但是a的功能比b多，a的功能序列通过在b的功能序列中的某个执行点插入追加的功能序列而构成，被称为例子a扩展例子b。 如果

8、扩展用例，建模器既不知道何时会发生需要执行附加操作序列的情况，也不知道发生的可能性。 将a的附加动作在b的动作序列中的插入点称为a对b的扩展点。 扩展关系经常用于区分正常的业务处理功能和异常处理功能，可避免异常处理逻辑的混乱和正常处理逻辑的消失。 例如，在课程登记管理系统中，对各课程设定中收容的学生数量有限制，若超过限制则需要任意的课程教师的同意。 可以设定“建立选择修订画面并考虑学生人数的限制”的用例，将其作为“建立选择修订画面”的扩展用例(参照图4.1 )。 2020/7/31，15，继承关系结果a和b相似，a的动作序列是通过改写b的部分动作、扩展b的部分动作得到的，称为用例a继承例b。

9、例句间的继承关系也必须符合类间的继承关系的代替性原则：任何特化例句都适用于该泛化例句的情况。继承关系与扩展关系非常相似，在面临实际问题时，如果能够指出明确的扩展点，则需要区别采用扩展关系的正常业务处理功能和带异常处理的功能，请采用扩展关系。如果不仅要插入新的动作，而且要修改原来的动作，请使用继承关系例如，假设在课程登记管理系统中，各学生选择的课程的总学时数不能超过所指定的限度，但对于优秀生(Excellent Student )能够放宽该限度，则设定“制作优秀生课程”用例例如，如果在例子a、b、c和d之间存在包含关系，则建模者采用了功能分解方法，表明该方法与例子建模的所需步骤不一致，并且不符合

10、面向对象的想法在用例图中，每个参与者必须至少与一个用例相关联，相反，每个用例必须至少与一个参与者相关联，包括并扩展的使用例外除外。 如果参与者没有与用例相关联，则不需要在用例图中显示。 如果继承的用例没有与参与者关联，则必须将其与特殊用例集成(用于用例继承)。 2020/7/31，17，用例之间的关系，(3)参与者之间的关系继承关系类似于面向对象的基本继承关系，但主要强调子类参与者继承父类参与者和用例之间的交互。 在参与者b继承参加者a，a触发执行用例UC的情况下，b和UC之间的触发执行关系不需要被明确表示。 例如，在图4.1中，参加者“Excellent Student”隐含地启动“授课表和

11、授课信息的询问”用例，但是在“制作课程表”用例和其扩展用例“制作考虑了学生人数限制的课程表”之间实现主要参与者建议放置在用例图的左上角。 触发用例运行的主动参与者必须位于用例的左侧，而接收用例生成的信息的被动参与者必须位于用例的右侧。 多个用例在垂直方向排列。 如果例子a的执行时间一定在b之前，最好把a放在b之上。 在水平方向上绘制包含关系，并将包含的用例配置在包含用例的右侧。 垂直绘制扩展和继承的关系，在扩展用例下放置扩展用例。 在继承的用例下放置继承的用例。 2020/7/31、19、4.1.3用例的显示在用例图中只能显示布局，只能显示每个用例的名称，通过正确记述用例的功能、参加者和用例之

12、间的信息流、交互序列等对于用例图中的每个用例，用例名称用例的功能或其业务目标与用例关联的参与者用例执行的触发条件(可选)用例执行的前置条件(可选)基本交互进程扩展交互用例执行完成时的后置条件(可选)业务规则类图的节点表示系统中的类及其属性和操作类图的边缘之间的关系。 在需求获取或业务理解过程中，类图可用于表示域概念模型，即业务域中的概念和概念之间的关系。在需求分析阶段，类图可用于表示软件需求模型的静态结构部分。在软件设置和实现阶段，类图可用于表示类类图的结构在面向对象的分析和设置修订过程中起着核心作用。2020/7/31，22、图4.2课程注册管理系统的类图、2020/7/31，23、(1)类

13、、类的属性在UML中指示为可见性名称：类型复用=初始2020/7/31，24，(a )最简化的类图元素(隐藏属性和操作部分) (b )隐藏操作部分的类图元素(c )隐藏属性部分的类图元素(d )完整的类图元素，以及2020/7/UML是聚合关系与进一步的聚合(一般的)组合的两倍。 在图4.4中示出了这些显示实体。 (a )关联关系的显示、2020/7/31、26、(b )聚合关系的显示、(b )聚合关系的显示、图4.4类间关系的显示要素、2020/7/31。 在代码中，类a具有成员变量，变量类型表示类b的聚合关系是关联关系之一。 例如，“学生”和“老师”之间有非继承或聚合的语义关联。 这是因为

14、一个学生可能会选择一个老师打开的课程设置。 可以在关联的表现实体的两端标记参与关联的多重性、角色名称和约束属性。2020/7/31、28、类之间的关系、类之间的关系、(1)示出关联终端上的类可以与另一个终端上的类中的单个实例对象相关联的实例对象的数目，以及两个关联相关联UML的多重性表示为1，0.1(0或1个)、0.* (0到任意多个)、1.*(1到任意多个)、* (与0.*相同)、m.n。 例如，在图4.2中，每个学生可以选择0到多个课程设置，每个课程设置可以容纳0到多个学生。 多重性后的两个显示符关系到具体数量的上下界，可以直接表现与可视化模型相关联的业务规则，但由于规则改变后必须修改模型

15、，因此本书不推荐这样的使用方法。 具体的数量限制规则记载在类图的附属文件中即可，不需要直接标定在UML模型图中。2020/7/31、29类之间的关系，(2)角色名称描述关联中所涉及的类的对象扮演关联的角色或角色。 例如，在“学生”和“教师”的关联中，前者起“学习者”的作用，后者起“知识传达者”的作用。 (3)说明对于参与制约特性关联的对象或对象集的逻辑制约。 在需求工程阶段，这种约束必须直接用自然语言表达。 例如，图4.2中的“有序”表示，如果一门课程有多个教师，则演讲者必须位于助理教师的前面，因此他们之间有秩序。 2020/7/31，30，班级之间的关系。 UML将面向对象的聚合概念分为两种关系：“聚合”(aggregation )和“组合”(composition )。 在聚合关系中，作为部件类的对象可能是多个整体类对象的一部分，例如，一个学生可以同时加入多个兴趣组。在组合关系中，一个