搜索
SoftwareEngineering2009BeyondTechnology软件开发过程与质量保证第十一章用例（1）SoftwareEngineering2009第九章用例9.1再谈需求9.2用例模型9.3用例产生过程9.4补充性规格说明掌握用例的三种描述形式重点和难点SoftwareEngineering2009前言用例就是需求，它主要是说明系统如何工作的功能性或行为性需求。用例强调了功能性或行为性，但也可用于其他类型，特别是与用例紧密相关的那些类型。在RUP中，用例被推荐为发现和定义需求的核心机制。SoftwareEngineering2009再谈需求RUP中需求的特点项目的初始阶段不彻底地分析和编写需求。通过一系列需求讨论会，并辅以及早的具有产品品质的编程和测试。早期开发中的反馈可用于精化规格说明。在初始阶段，确定大部分需求的名称，详细分析10%的用例。对于其他部分的需求描述将在细化阶段进行。进化式需求一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求。第九章用例9.1再谈需求SoftwareEngineering2009跨越早期迭代的需求任务科目制品初始（1周）细化1（4周）细化2（4周）细化3（3周）细化4（3周）需求用例模型2天的需求讨论会。定义大多数用例的名称，并附以简短文字摘要从高阶列表中选择10%的需求加以分析并详细编写。这10%的用例应具有重要的架构意义、风险和高业务价值的在本次迭代接近结束时，举行2天的需求讨论会。从实践工作中获取理解和反馈，然后完成30%的详细用例。在本次迭代接近结束时，举行2天的需求讨论会。从实践工作中获取理解和反馈，然后完成50%的详细用例。重复，详细完成70%的用例重复，确定80%~90%的详细用例，并详细编写。其中只有一小部分在细化阶段构建，其余在构造阶段实现设计设计模型无对一组高风险的、具有重要架构意义的需求进行设计重复重复重复。高风险和重要架构意义的方面现在应该稳定化实现实现模型（代码等）无实现之重复，构建了5%的最终系统重复，构建了10%的最终系统重复，构建了15%的最终系统项目管理软件开发计划十分粗略地估计整体工作量预算开始成形少许改进……少许改进……现在可以提交合理的总体项目进程、主要里程碑、工作量、成本预算SoftwareEngineering2009对表的解释当仅仅定义约10%的需求时，技术小组就开始构建系统的产品化核心。通过细化阶段，给予对部分系统增量构建的反馈、调整以及在若干迭代开发，其他需求将更为清晰并且可以记录在补充性规格说明中。在细化阶段结束时，完成并提交用例、补充性规格说明和设想是切实可行的。通过构造阶段，主要需求（包括功能性需求和其他需求）已经基本稳定下来。因此，在该阶段补充性规格说明和设想都不必进行大量改动。SoftwareEngineering2009在初始阶段中重要需求制品用例模型补充性规格说明SoftwareEngineering2009第九章用例9.1再谈需求9.2用例模型9.3用例产生过程9.4补充性规格说明SoftwareEngineering2009用例的概念定义一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的返回值。含义用例是一个自包含的单元用例必须由参与者发起并监控用例必须完成一个特定目标用例应该使系统保持在稳定状态第八章面向对象方法的获取8.3用例SoftwareEngineering2009用例是黑盒风格需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。例子黑盒风格非黑盒风格系统记录图书信息系统将录入图书信息写入数据库。……或者（更糟糕的描述）系统对录入图书信息生成SQLINSERT语句…...SoftwareEngineering2009用例模型是所有书面用例的集合是系统功能性和环境的模型用例模型中可包括UML用例图，以显示用例和参与者的名称及其关系SoftwareEngineering2009参与者概念也可称为执行者。是任何具有行为的人或事物。参与者和用例通信并且期待它的反馈——一个有价值或可觉察的结果。SoftwareEngineering2009参与者的类型有三种主要参与者•具有用户目标，并通过使用当前系统的服务完成。例如，收银员。他们是发现驱动用例的用户目标。协助参与者•为当前系统提供服务。例如，自动付费授权服务。协助参与者通常是计算机系统，但也可以是组织或人。通过协助参与者可以明确外部接口和协议。幕后参与者•在用例行为中具有影响或利益，但不是主要或协助参与者。例如政府税收机关。幕后参与者的确定确保确定并满足所有必要的重要事务。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。SoftwareEngineering2009用例的描述三种常用形式摘要•简介的一段式概要，通常用于主成功场景非正式•非正式的段落格式。用几个段落覆盖非正式场景详述•详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保障。用例是文本形式的。SoftwareEngineering2009详述形式的用例模板内容用例的不同部分用例名称范围级别主要参与者涉众及其关注点前置条件成功保证基本流程分支流程特殊需求技术和数据变元表发生频率杂项以动词开始要设计的系统“用户目标”或是“子功能”注释调用系统，使之交付服务关注该用例的人及其需要值得告知读者的，开始前必须为真的条件值得告知读者的，成功完成必须满足的条件影响对实现的调查、测试和时间安排例如未解决问题典型的、无条件的、理想方式的成功场景成功或失败的替代场景相关的非功能性需求不同的I/O方法和数据格式SoftwareEngineering2009用例的可视化描述藏宝者图书管理统计晒书计划借阅还书上报图书信息登录藏书室资料管理员系统管理员用户管理规则制定系统设置actor院图书管理系统系统边界通信计算机系统参与者表示法参与者用例关系SoftwareEngineering2009用例之间的联系参与者1用例1用例2用例4用例3用例5参与者2includecommunicatecommunicateextend单向单向关联泛化SoftwareEngineering2009总结要求了解理解掌握1、进化式需求的含义2、用例的定义1、用例的三种描述形式具体内容