第章需求获取.ppt

框架用例的主要创建者是需求工程师（团队）。用户和客户是本活动的重要参与者，负责提供相关的信息和咨询，其中至少应有一人能够扮演业务领域专家的角色。 * 基本交互动作序列的描述方法 ⑺避免嵌套地使用“如果……，那么……”。 因为基本交互动作序列仅考虑最典型的场景，某些条件不成立时的动作可以推迟到扩展交互动作过程中描述。 如，基本交互动作序列： 1．用户输入用户名、密码。 2．系统检查用户名、密码是否正确。如果正确，则： 2.1 用户输入课程名、任课教师、上课时间及教室。 2.2 系统检查……。 应修改为： 1．用户输入用户名、密码。 2．系统检查用户名、密码的有效性。 3．用户输入课程名、任课教师、上课时间及教室。 4．系统检查……。 * * 基本交互动作序列的描述方法 ⑻在一连串动作的前部或后部描述循环、特殊的时序约束或其他有关此子动作序列的其他说明。 例如，循环可采用类似于下面的方式说明（前部） 1．…… 步骤2-3可以循环执行，直至…… 2．…… 特殊的时序约束可采用类似于下面的方式说明（后部） 1．…… 2．…… 3．…… 步骤2、3发生的时序是任意的。 * * 基本交互动作序列的描述方法 ⑼如果用例A包含子用例B，那么在A的动作序列描述中采用带下划线的子用例B的名称来引用B的交互动作序列； 类似地，如果有一个子动作序列在A中被多次使用，或者单独描述该子动作序列有助于用例动作序列的结构清晰性，可以对其命名并通过带下划线的名称引用来避免重复。 例如， 1．…… 2．用户选择注册课程、撤销注册或确认选课计划： 2.1 用户选择注册课程：执行注册课程子流程。 2.2 用户选择撤销注册：执行撤销注册子流程。 2.3 用户选择确认选课计划：执行确认选课计划子流程。 …… 注册课程子流程： …… 撤销注册子流程： …… 确认选课计划子流程： …… * * （二）扩展交互动作序列的描述方法 扩展交互动作序列的描述方法是： ⑴标识可能出现特别情形的基本交互动作序列中的动作的编号 ⑵说明扩展分支的条件以及在此条件下的处理动作序列 ⑶描述扩展处理完成后与基本动作序列的汇合点。 * * 扩展条件及扩展动作序列编号方式 一般用基本动作序列中的动作编号加英文字母来标引扩展条件，它表示在基本动作序列中的相应步骤可能出现条件所示的情形。 相应的扩展动作序列则以条件标号再加动作序号来表示。 例如，“1.1a 任课教师在同一时间已安排其他课程设置”表示在基本动作序列的第1.1个步骤可能出现意外。“1.1a1 ……”表示冲突出现时的第1个处理动作。 为保持版面清晰，扩展动作序列应基于扩展条件向右缩进。 * * 扩展交互动作序列的描述方法 如果在基本动作序列的同一步骤会出现多个分支条件，则条件标号的字母依字母表的顺序向后延伸，但这种延伸并不隐含时序关系方面的意义。 最后，如果在扩展动作序列中再出现分支条件，那么可综合采用上述条件标号规则、扩展动作序列编号规则和版面编排规则，直接在一个扩展动作序列中嵌套地表示另一子扩展条件及其动作序列，见例4.8?。 扩展的嵌套不宜过深。如果确有需要，建议分离出单独的扩展用例以减少扩展嵌套深度。 单独扩展用例也可用在多个步骤扩展出来的相同动作序列，无论扩展条件是否相同。 * * 扩展交互动作序列的描述方法 例如，用例“制订课表”包含了子用例“在课表中添加课程设置”和“在课表中修改课程设置”，两个子用例中的扩展条件“在同一时间针对同一教师安排了多门课程设置”、“在同一时间同一教室安排了多门课程设置”、“在同一时间针对同一专业的学生安排了多门课程设置”在用例“制订课表”中应归并为单个扩展条件：“课程设置有冲突”。 * * 4.5.2 分解或合并用例 用例粒度：是指用例对应的功能范围相对于整个软件产品的功能而言的规模比。 在同一用例模型中，往往不希望用例的粒度过于悬殊。 分解或合并用例的准则： ⑴用例具有业务意义上的相对独立性和完整性。 ⑵应遵循业务层面上的强内聚、松耦合原则。 ⑶一个软件系统的用例不宜过多 用例总数一般应控制在20以内，最多不超过30。 对于特别大型的软件系统，可先分解为子系统，然后针对每个子系统分别考虑用例的粒度 可借助UML包图表示系统的划分，并将用例指派到包中。 ⑷用例的粒度应确保合理规模的软件开发团队能够在合理的时间周期内实现该用例 * * 分解或合并用例 当系统中用例数量很多时，可以按照以下原则适当地合并一些粒度较小的用例。 ①合并业务上关系比较密切的多个用例。 例如，针对课程注册管理系统，可以将“注册课程”、“撤销注册”两个用例合并为“制订选课计划”用例。 ②在同一业务范围内，合并功能上相似的用例。 例如，在家庭保