Lecture4.ppt

《Lecture4.ppt》由会员分享，可在线阅读，更多相关《Lecture4.ppt（53页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、系统分析与设计系统分析与设计郑大鹏郑大鹏第六章 用例和用例模型目标：n确定和编写用例n使用摘要、非正式和详述等用例形式n将测试应用于适当的用例上n将用例分析与迭代开发联系起来6.1 什么是用例 用例是文本形式的情节描述，用于描述某参与者使用系统以实现某些目标的情节。例如下面的文本描述就是处理销售的摘要形式的用例：处理销售的摘要形式 处理销售：顾客携带所购商品到达收银台。收银员使用POS系统记录每件商品。系统连续显示累计总额并逐行显示细目。输入顾客支付信息，系统对支付信息进行验证和记录。系统更新库存信息。顾客从系统得到购物小票，然后携商品离开。6.2 为什么使用用例 用户的参与是软件成功的重要保

2、证。用例是一种优秀的方法，使领域专家和用户能共同参与以提供正确的需求，用例强调了用户的目标和观点。用例能够根据需要对复杂程度和形式化程度进行增减调节。用例强调了功能性需求，即“FURPS+”中的“F”，也可用于其他需求，用例是发现和定义需求的核心机制。用例定义了系统行为的契约。6.3 用例和用例模型(Use-Case Model).UP在需求科目中定义了用例模型。用例建模主要是编写文本的工作，用例模型是文本文挡，它是所有书面用例的集合，也是系统功能性和环境的模型。用例模型还可以包含UML用例图，以显示用例和参与者的名称及其关系。用例不是面向对象的，也不进行OO分析，但是用例是经典的OOA/OO

3、D的关键需求输入。6.4 参与者、场景和用例 1.参与者 参与者(actor)是某些具有行为的事物，可以是人、计算机系统或其它机构、相关的软件系统甚至是系统自身（当它调用其它系统的服务时）。有三种参与者：1）主要参与者，用例的发起者，具有用户目标。2）协助参与者，为系统提供服务的系统或机构。3）幕后参与者，在用例行为中具有影响或利益关系，如销售系统中要考虑到政府税收机构。2.场景 场景(scenario)是参与者和系统之间的一系列特定的活动和交互，场景也称为用例的实例(use case instance),一个场景是使用系统的一个特定情节或用例的一条执行路径。因此，用例就是一组相关的成功和失败

4、的场景集合。其中每一个场景都是系统执行的一系列活动，这些活动产生了对某个参与者可观察的返回值。场景分为主成功场景和非主成功场景。6.5 用例的三种常用形式 用例可用三种不同形式化程度或格式进行编写：1.摘要形式：简洁的一段式概要。通常用于主成功场景。摘要形式用在早期需求分析中，为快速了解主题和范围，几分钟完成。2.非正式形式：非正式的段落格式。用几个段落覆盖不同场景。非正式形式也是用在早期需求分析中，但主要用于交替场景，而非主场景。3.详述形式：详细编写所有步骤及各种情况，同时具有补充部分，如前置条件和成功保证（后置条件）。详述形式在以摘要形式编写了大量用例后使用，在多次迭代中逐步完善。在第一

5、次需求讨论会中，通常只详细编写其中少量（如10%）的具有重要架构意义和高价值的用例。6.6 详述形式的用例的模板用例的组成部分 注释用例名称 以动词开始范围 要设计的系统级别 用户目标或子功能主要参与者 调用系统使之交付服务涉众及其关注点 关注该用例的人及其关 心的需求前置条件 值得提醒的开始前必为 真的条件成功保证 值的提醒的成功必须满 足的条件主成功场景 典型的无条件的理想下 的成功场景扩展 成功或失败的替代场景特殊需求 相关的非功能性需求技术或数据变元表 不同的I/O方法和数据格式发生频率 会影响对实现的调查、测 试和时间安排杂项 一些未决问题6.7 详述形式的用例例子（处理销售）及解释

6、：1.范围：范围界定所要设计的系统。本例为:NextGenPOS应用 2.级别：用户目标级别和子功能级别 1）用户目标级别(user-gol-level)：通常使用的级别,实现主要的参与者目标的场景。大致相当于业务流程工程中的基本业务流程(Elementary Business Process,EBP).2)子功能级别(subfunction-level)：描述支持用户目标所须的可被共享的重复的公共子步骤。本例为用户目标 3.主要参与者：系统用例的发起者。本例为收银员。4.涉众及其关注点：用例是涉及系统和应用相关的行为契约。因此与该用例有关的人和事的关注点要首先并详细列出，以便确定详细的系统职

7、责。本例的涉众及其关注点描述如下：-收银员：希望能够准确、快速地输入，正确地计算和记录支付。错误的支付将导致收银员被罚。-售货员：希望自动更新销售提成。-顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看到所输入的商品项目和价格。希望得到购买凭证，以便退货。-公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能完成销售。希望能够自动、快速地更新账务和库存信息。-经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。-政府税收代理：希望能从每笔交易中抽取税金。可能存在多级税收

8、代理，如国税、地税等。-支付授权服务：希望接收到格式和协议正确的数字授权请求。希望准确计算对商店的应付款。5.前置条件和成功保证（后置条件）1）前置条件 前置条件(precondition)给出在用例中场景开始之前必须为真的条件。用例中不会检查前置条件。通常，前置条件隐含已经成功完成的其他用例场景，必须写出的前置条件是那些应该引起警惕的条件。本例中的前置条件是：收银员必须经过确认和认证。2）成功保证（后置条件）后置条件给出用例成功结束后必须为真的事物，该保证应满足所有涉众的需求。本例中的后置条件为：存储销售信息；准确计算税金；更新账务和库存信息；记录提成；生成票据；记录支付授权的批准。6.主成

9、功场景和步骤（或基本流程）主成功场景也称“理想路径”场景，有时也称为“基本流程”或“典型流程”。它描述了满足涉众关注点的典型成功路径。通常不包括任何条件或分支。条件或分支延迟到扩展部分。场景记录以下三种步骤：1）参与者之间的交互。2）确认通常由系统来完成的过程 3）系统完成的状态变更 本例中主成功场景如下：1.顾客携带所购商品或服务到收银台通过POS机付款。2.收银员开始一次新的销售交易。3.收银员输入商品条码。4.系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。价格通过一组价格规则来计算。收银员重复34步，直到输入结束。5.系统显示总额和所计算的税金。6.收银员告知顾客总额，并请顾

10、客付款。7.顾客付款，系统处理支付。8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理 9.系统打印票据。10.顾客携带商品和票据离开。7.扩展（或替代流程）扩展部分描述了主成功场景之外的其他所有场景或分支，包括成功和失败路径。因此往往占有更大的篇幅。理想路径与扩展路经相结合应该满足“几乎”所有涉众所关心的问题。当然，有些问题可作为非功能性需求在补充规格说明中描述，以使用例文本更加清晰。编写扩展用例时应注意：1）扩展场景是对主成功场景的分支，因此能够以对应的步骤1N对其进行标识。如本例中主成功场景第3步为收银员输入商品ID，这里有两个问题需要说明：一是当出现无效的

11、商品ID时应该如何处理；一是当顾客购买多个同类产品时应该如何处理。于是扩展场景可标识并编写为:3a.无效商品ID:1.系统提示错误并拒绝输入该标识.2.收银员响应该错误.3b.当有多个商品属于同一类别时(如5个汉堡),不必记录每个商品的ID:1.收银员可以输入商品标识和商品数量.2）扩展由两部分组成：条件和处理。应尽可能使用系统或参与者能够检测到的事物作为条件。对比下面两个条件:5a.系统检测到与外部税务计算系统服务的通信故障。5a.外部税务计算系统工作不正常。第一种风格更好,因为这时系统能检测到的条件。而第二种只是一种推断。3）扩展处理可以针对一个步骤，也可以针对一系列步骤，当一组步骤中都出

12、现相同条件时，可以简化描述。如本例中当操作在第3到第6步中间（即录入商品并显示累计金额）时顾客要求从购买的商品中去掉一项，此时的扩展可标识并描述为：3-6a.顾客要求收银员从所购商品中去掉一项：1.收银员输入商品ID并将其删除。2.系统删除该项目并显示更新后的累计额.4）当扩展处理结束时，默认情况下将回到主成功场景，除非扩展指出了其他方式。5）当扩展点非常复杂时，例如本例中的信用卡支付扩展,可以使用单独的用例来表示扩展。6）扩展可以嵌套。例如前面提到的处理无效商品ID时：3a.无效商品ID（读商品ID 时出错）:1.系统提示错误并拒绝输入该标识.2.收银员响应该错误：2a.商品ID可读（如数字

13、型的UPC）（手工输入）2b.系统内不存在该商品，但该商品附有价签 7）如果要描述在任何步骤或大多数步骤都可能发生的扩展，那么可以使用*a、*b这样的标识。例如本例中在主成功场景后:扩展(或替代流程):*a.经理在任意时刻要求进行超控操作：*b.系统在任意时刻失败:8）执行其他用例场景：有时用例会产生分支去执行其他用例场景。如“寻找产品帮助”是一个单独的用例，该用例有时会在销售用例中执行（当无法识别商品ID时）。在用例描述中可以通过在用例名称下加下划线来标识被调用的用例。如：“收银员通过执行寻找产品帮助以获取正确的商品ID及其价格”7.特殊需求：与用例有关的非功能需求、质量属性或约束也应该写入

14、用例，如设备的要求、时间的约束等，当然也可以把它们归到补充规格说明中。8.技术和数据变元表：需求分析中有时会涉及到一些与设计有关的要求（如通常客户会对I/O设备提出要求，或对使用的标准代码提出要求）。一般来说，应该避免早期不成熟的设计决策，但有时这些决策免不了，就要写入用例。6.8 两栏式用例格式 可以使用两栏式的对话格式编写用例.该格式展示参与者和系统之间的交互.主成功场景:参与者的活动(或意图)系统的响应1.顾客携带所购商品到收银台通过 POS付款.2.收银员开始一次新的销售交易.3.收银员输入商品ID .4.系统逐条记录出售的商品项目,并显示 该商品的描述、价格和累计额.5.收银员重复出

15、34步直到结束 .6.系统显示总额和所计算的税金.7.收银员告知顾客总额并提请付款.8.顾客支付.9.记录完整的销售信息,并将销售和支付 信息发送到外部的账务系统和库存系 统,系统打印票据.6.9 编写用例的若干准则 一、以无用户界面约束的本质风格编写用例 假设在管理用户用例中需要标识身份和认证：本质风格：与实现细节无关 .1.管理员标识自己的身份。2.系统对此身份进行验证。.具体风格：与实现细节有关 .1.管理员在对话框中输入ID和口令（见图3）2.系统对此身份进行验证。3.系统显示“编辑用户”窗口（见图4）.在早期需求阶段,应避免这种具体风格。如何实现需求留到设计阶段决定。二、编写简洁的用

16、例 准确而又精炼三、编写黑盒用例 不对系统内部工作、构件或设计进行描述,而要通过职责来描述系统。用例只描述系统做什么，而不描述系统如何做。如：黑盒风格 非黑盒风格 系统记录销售 系统将销售信息写入数据库。(或更糟的描述:系统对销售 信息生成SQL INSERT语 句）四、采用参与者和参与者目标的视点 用例的每一个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。因此要强调需求分析的两个重要关注点：1）关注系统的用户或参与者来共同编写需求，确定用户认可的目标和场景。2）关注开发者是否理解用户所考虑的有价值结果。6.10 如何确定用例一、确定用例的基本准则 确定用例的基本准则

17、是用例应该满足主要参与者的目标需求二、确定用例的基本过程 1)选择系统边界 2)确定主要参与者 3)确定每个主要参与者的目标需求 4)定义满足用户目标的用例 （一）选择系统边界 1.什么是要被设计的系统？2.什么在系统之内（你必须投入大量精力来创建的事物）？3.什么在系统之外（你不需创建，但必须考虑与它们的接口的事物）？如在本例中，POS系统是要被设计的系统。收银员是使用系统的人，在系统之外。同样，支付授权服务是系统外的机构或系统。（二）确定主要参与者和他们的目标 1.集体决定什么是主要参与者。主要参与者应是用例的发起者。2.确定其它的参与者，与系统交互的所有事物都是系统的参与者。为确定参与者

18、，可以参考下列问题：谁使用这个系统？谁安装这个系统？谁启动这个系统？谁维护这个系统？谁管理这个系统？谁关闭这个系统？哪些其它系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？是否有事件在预定的时间发生？系统有必须响应的其他外部事件吗？3.如何组织参与者和目标 至少有两种方法用以组织参与者和目标:1）绘制用例图并以目标作为用例名称。2）编制参与者和他们的目标列表，再绘制用例图。参与者-目标列表可作为愿景制品的一部分。例如：参与者与目标列表 参与者参与者 目标目标 参与者参与者 目标目标 收银员收银员 处理销售处理销售 系统管理员系统管理员 增加用户增加用户 处理退货处理退货 修改用户

19、修改用户 入账入账 删除用户删除用户 出账出账 管理安全管理安全 经理经理 启动系统启动系统 分析系统分析系统 分析销售分析销售 关闭系统关闭系统 (四)定义用例 根据所有的参与者及其目标，为每一个参与者确定用例；用例的名称就是参与者的目标。每一个用例描述一个参与者想要系统完成的事情；所有的用例共同描述从用户的角度看到的系统的完整功能。例如：用例列表 用例名称 参与者 目标 处理销售 收银员 处理销售 处理退货 收银员 处理退货 入账 收银员 入账 出账 收银员 出账 启动系统 经理 启动系统 关闭系统 经理 关闭系统 用例列表（续）用例名称 参与者 目标 增加用户 系统管理员 增加用户 修改

20、用户 系统管理员 修改用户 删除用户 系统管理员 删除用户 管理安全 系统管理员 管理安全 分析销售 分析系统 分析销售 6.11 UML用例图 UML提供了用例图表示法。用例图直观地描述了用例名称和参与者及它们之间的关系。应该说明的是，在编写用例过程中，重点是编写用例文本，用例图及用例关系只是一种辅助手段。用例图的优点是能够为系统提供简洁可视的语境图，能够展示系统边界，阐述外部参与者及其对系统的使用。下面是示例：UML用例图用例图 处理销售处理退货分析销售管理安全性管理用户收银员收银员经理经理支付授权服务支付授权服务税金计算器税金计算器会计系统会计系统actor 销售分析系统系统管理员系统管

21、理员绘制用例图因注意的问题：1）用例图能够为系统提供简洁可视的语境图，有助于说明系统边界、外部参与者及其对系统的使用。因此用例图应该简单，并与“参与者目标”列表关联。2）绘制用例图时，主参与者（用例的发起者）放在左边，其它参与者放在右边。3）通常参与者如果是人，用一个人形表示，参与者如果是人以外的事物，用一个方框表示，以示区别。6.11 UML活动图 UML包含一种有助于使工作流和业务过程可视化的图即活动图。活动图类似于传统的程序流程图。由于用例涵盖过程和工作流，因此活动图也可以作为编写用例的辅助措施，特别是对于具有复杂工作流的用例。例如一个系统登录的活动图如下：一个系统登录的活动图显示登录界

22、面显示登录界面输入姓名密码输入姓名密码信息验证信息验证设置进入权限设置进入权限显示主界面显示主界面6.12 系统特性(功能)列表 前面已经说明,用例就是需求,而且主要是表达功能性需求。但是在愿景文档中,有时使用系统特性(功能)列表是有用的。通过加入高层特性列表有助于概括系统的功能性要求。高层特性列表在较大的范围概括系统功能，通常仅包含几十个条目。系统特性(功能)列表独立于用例。在有些场合，用例不一定合适。某些应用迫切需要功能驱动，此时，需要用详细的特性列表代替用例。详细的特性列表通常可能包含几百上千个条目。当不使用用例而使用功能列表时注意以下概念：一、系统功能与系统属性 系统功能(system

23、 function)是系统应该做的事。而系统属性(system attribute)是系统的非功能特性，例如易于使用、响应时间等。二、功能的分类 系统功能可以分为三类：1.明显的:应该履行的功能,并且用户能直接感知该功能是否被履行;2.隐藏的:应该履行的功能,但功能是否被履行对用户不可见。如信息存库。3.修饰性的:可选的,增加这样的功能不会对成本和其他系统造成重要影响。三、系统功能列表示例例如POS应用的部分功能可以列表如下：标号 功能 分类R1.1 记录在线的销售 明显的R1.2 计算当前的销售总额,包括 税金和优惠折算 明显的R1.3 当一次销售提交后,修改库存量 隐藏的 四、系统属性 系

24、统属性是非功能的特性。系统属性可以针对某一个、某一些或跨越系统的所有功能。系统属性具有一组可能的属性细节，例如：界面形式=（图形化的、彩色的）一些系统属性还可能具有属性边界约束，如：响应时间=（最长5秒）本次课小结本次课小结n用例是系统的使用场景、情景、过程；用例是系统的使用场景、情景、过程；n系统的需求可以通过系统的操作者和系统的需求可以通过系统的操作者和相关用例说明；相关用例说明；n用例驱动的方法是指在需求阶段建立用例驱动的方法是指在需求阶段建立用例模型，分析、设计、实现及测试用例模型，分析、设计、实现及测试都从用例入手的开发方法；都从用例入手的开发方法；课后作业课后作业n以小组为单位，编写网上购物系统用以小组为单位，编写网上购物系统用例，下周讨论。例，下周讨论。