第6章组织系统需求：用例描述和图

第6章组织系统需求：用例描述和图使用“用例”来表达系统的功能需求的分类功能性需求：系统应当具备的功能，即系统必须能够做什么、完成哪些工作。非功能性需求：系统精确度、性能、效率、成本、可维护性、安全性等系统行为之外的系统质量需求。用例建模：捕获系统的功能性需求，帮助人们理解系统需求，而无需关注系统如何实现本章内容分辨信息系统的边界什么是用例用例的概念、目的识别参与者识别用例绘制用例图如何描述用例用例分解，确定用例关系6.1.1用例的概念用例创始人雅各布森IvarJacobson认为：用例（usecase）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。阿里斯代尔·科克伯恩AlistairCockburn：强调用例是各种系统受益人（stakeholder）之间的一种行为契约（contract）。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是为了达成某种目标，因此每一个用例实际上都应代表一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。UseCase的定义在一个workshop(专题讨论会)上，14位主要的OO专家对UseCase有14个定义。定义1：usecase是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列(见[2])。定义2：Thespecificationofsequencesofactions,includingvariantsequencesanderrorsequences,thatasystem,subsystem,orclasscanperformbyinteractingwithoutsideactors.(见[3])[2]

邵维忠，杨芙清，面向对象的系统分析，p153[3]J.Rumbaugh,etc.TheUnifiedModelingLanguageReferenceManual,p488用例的意义用例是对系统需求（主要是功能需求）的规范化的描述。用例图及用例的事件流描述集中体现了系统责任，通过用例建立交互图。交互图就是用例的具体实现，即系统中的对象以及对象间协作是如何完成一个用例的全部过程。用例驱动的开发过程，从用例模型到分析模型和设计模型之间有一致性和可追踪性。用例是代表系统中各个相关人员之间就系统的行为所达成的契约。例：在线银行系统的一些可能的用例：浏览帐户余额列出交易内容划拨资金支付帐款登录退出系统编辑配置文件买进证券卖出证券UseCase驱动usecase对软件开发的意义实现测试分析设计UseCases把所有这些过程绑到一起usecase说明：Usecase从使用系统的角度描述系统中的信息，即站在系统外部察看系统功能，并不考虑系统内部对该功能的具体实现方式。使用usecase可以促进与用户沟通，理解正确的需求，同时也可以用来划分系统与外部实体的界限，是OO系统设计的起点，是类、对象、操作的来源。9用例的一些特点：（1）用例描述了用户提出的一些可见的需求；（2）用例可大可小；（3）用例对应一个具体的用户目标。理论上我们可以把一个软件系统的所有UseCase画出来，但实际运用时只需把重要的、交互过程复杂的那些画出来。需求有两种基本形式：功能性和非功能性的。不是所有的需求都要用usecase表示出来。问题：一个系统的需求包括哪些内容？可以参照需求大纲10用例建模的内容基于用例的需求获取过程：1.获取原始需求2.开发一个可以理解的需求识别参与者识别用例构建用例图3详细、完整地描述需求书写用例规格说明4重构用例模型识别用例间的关系对用例进行组织和分包1、识别参与者参与者是系统之外与系统进行交互的任何事物。使用系统的个人谁负责提供、使用或删除信息？谁将使用某项功能？系统所连接的外部硬件。例如，控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。与该系统进行通信的其他信息系统。例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。信用卡系统是销售系统中的一个参与者区分参与者和外部实体只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。如果学生直接通过Web方式提交个人信息，则认为学生是参与者。区分主要参与者和次要参与者主要参与者（primaryactor）是从系统中直接获得可度量价值的用户。次要参与者（secondaryactor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用用例分析的重点是要找到主要参与者。比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。事件触发源操作输出目标读者检查库存书目书目查询请求读者提供书目供检索书籍列表读者读者借书借书单读者登记借书记录书借书记录读者通过事件表获得参与者：参与者可以从“源”得到启发，但“源”表示数据最初的提供者，不一定对应功能的执行者。参与者举例参与者的表示在UML中，参与者使用小人符号：图书馆系统读者图书管理员RSA中的建模符号参与者的泛化在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。2、识别用例用例就是功能性需求。每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。用例的UML图形表示购买商品Rose中的符号购买商品区分用例和用例完成的步骤不能混淆用例和用例所包含的步骤。比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。与结构化分析中提到的事件概念相同。区分业务用例和系统用例当针对整个业务领域建模时，需要使用业务用例比如图书馆系统有一项重要工作就是“整理书架”，图书都要放回到固定的位置上信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导发送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。用例举例1用例举例2在门诊挂号处只能挂当天的号，挂出的号可以退。病人拿到挂号单后，到相应的科室进行就诊。医生根据挂号的顺序号，依次给病人看病开处方。病人拿处方去收款处交费，并拿到发票。病人拿已经收费的处方去药房拿药。该系统潜在的参与者和用例有哪些？图书馆系统的用例图进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。扩展和包含关系就是用例模型中消除冗余的一种手段。基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。6.2用例关系用例关系包含关系：经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。扩展关系：表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例。泛化关系：如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。包含用例是基本用例存在的必要条件一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。取款修改口令身份识别<<include>><<include>>包含关系扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。扩展用例的缺失不影响对基本用例的理解。打电话来电显示三方通话<<extend>><<extend>>扩展关系用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。父用例通常是抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整的，这一点与包含关系扩展关系不同。订购网上订购电话订购泛化关系（不推荐）小结：actor，usecase的关系(relationship)类型说明：可在usecase间建立关联，但意义不是很明确。association关联:actor和usecase之间的关系包含:usecase之间的关系includeextend扩展:usecase之间的关系generalization泛化:actor之间或usecase之间的关系关系类型说明表示符号30用例的粒度通常用例图粒度较大通过分解和细化，可以使粒度更小通过事件流描述：寻找用例的共同点寻找用例的扩展点切忌“画蛇添足”！常见问题分析1.Usecase的粒度问题，即对于一个系统的UseCase图，所包含的用例数目问题。这是很多人争论的重点。例如，IvarJacobson说，对一个十人年的项目，他需要二十个用例。而在一个相同规模的项目中，MartinFowler*则用了一百多个用例。*《UMLdistilled》一书的作者322.许多应用中需要对系统访问进行控制，应该如何处理登录问题比较好？有四种处理登录用例的方式:(1)其它用例包含登录;(2)其它用例扩展登录;(3)登录独立于其它用例;(4)登录包含其它用例。33(1)其它用例包含登录用例说明:……这种处理方式的特点:34(2)其它用例扩展登录用例说明:……这种处理方式的特点:35(3)登录独立于其它用例。用例说明:……这种处理方式的特点:36登录用例说明:1.当超级用户启动应用时用例开始2.系统提示超级用户输入用户名和密码3.超级用户输入用户名和密码4.系统验证其是否为有效超级用户5.用例结束调入员工用例说明:前置条件:一个有效超级用户登录了系统37(4)登录包含其它用例用例说明:……存在的问题:383.假设有这样需求：学生档案管理中，用户经常需要做三件事：增加一条学生记录、修改一条学生记录，删除一条学生记录。如果要画出usecase图，以下2种方法哪种更合适？方法1：再分成3个脚本，分别画3个交互图。脚本1增加学生记录；脚本2修改学生记录；脚本3删除学生记录。方法2：每个usecase画一个交互图。398.4.4合理组织用例对用例进行分包让用例图能够更为清晰地表现出系统的业务逻辑关系和层次对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式常见的分包方式按参与者分包，如读者包、图书管理员包按主题分包，如毕设的题目管理包、成绩管理包按开发团队分包，A小组、B小组按发布情况分包，第1次迭代包…错误的用例图举例把步骤当用例把系统活动当用例错误的用例图举例Email客户端（如：outlookexpress），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件用例是一个完整的交互用例之间没有顺序的关系课堂练习：用例建模完成“旅店预定系统”的系统用例图，注意用例的命名和用例间的关系的使用。选择一个体现系统核心业务功能的用例，完成用例规格说明。“旅店预定系统”初步用户需求某公司要开发一个旅店预定系统，该旅店可对外开放豪华双人间、双人间、三人间和单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。问题用例图1问题用例图2问题用例图31.不恰当的“时间”参与者时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例“检查是否可以退定金”的时候，时间仅仅是一个系统内部的判断条件，而不是参与者2.无效的参与者泛化参与者泛化：特殊参与者会继承泛化参与者所有的要素！参与者的重要性在一识别用例，如果泛化没有带来任何用例，则这样的方法没有任何意义在系统中如果两个参与者涉及相同的用例，则合并3.错误的用例关系依赖关系：include,extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示扩展关系：“extend”关系的方向，子用例对主用例的扩展3.错误的用例关系用例的顺序在活动图中表现3.错误的用例关系4.“其他”用例？“其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？“其他”用例又代表什么呢？想说明什么样的功能需求？5.参与者和用例间的关系“打印报表”和“酒店管理员”之间的关联是有意义的交互吗？6.用例粒度太小用例规格描述常见错误用例描述中只有参与者动作，没有系统动作。用例描述中没有主参与者。描述中过多的用户接口细节，如按钮等界面元素的具体实现。描述过低的目标级别。较为合理的用例图8.4.2用例的描述用例图是对系统中的用例的高度概括和直观的表示，但没有细节。一个用例就象一个故事，使用文字叙述对用例进行详细描述。一个编写良好的用例应该具有很好的可读性，没有可读性的用例则一点儿用也没有。用例的描述可以有多种格式，从随意的语言描述到定义严格的用例模板，可根据实际情况选择。1、用例规格说明（模板）

UseCaseSpecification用例名称主要参与者/次要参与者简要描述前置条件后置条件主事件流（主要成功场景/基本路径）备选事件流（扩展路径/替代流程/异常事件流）特殊要求/非功能性需求发生频率2、用例与事件流（FlowofActivities）用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。事件流的描述包括：用例何时开始和结束用例何时与参与者交互参与者与系统之间有什么对象或信息被交换该行为的主事件流和备选事件流3、用例与场景（Scenarios）用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同的情节，称为变体。比如：购买商品的用例中收款可以是现金支付、信用卡支付或支票支付。针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。主成功场景：故事的主线，用例通常得到成功执行的典型场景。扩展场景：失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）4、用例的前置条件和后置条件前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到系统中。后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。某些用例可能没有前置条件或后置条件，比如“查询书目”。用例的简要描述用例名：购买商品参与者：出纳员简要描述：顾客带着所要购买的商品来到收款处。收款员记录下商品信息并收款。付款完成后，顾客带着所购买的商品和收据离开。购买商品收款员对“取款”用例的非正式描述1）用户插入ATM卡并输入密码2）用户选择取款并输入取款数量3）系统吐出现金，并从账号余额中扣除取款数对“取款”用例的完整描述主参与者：信用卡用户目标：用户使用信用卡从ATM机获取现金范围：银行ATM系统前置条件：用户将信用卡插入ATM触发事件：用户希望从ATM机上取现金主事件流：1）用户插入信用卡到ATM机2）ATM系统识别卡的ID和账号，并用主银行系统验证其有效性3）用户输入密码，ATM验证其有效性4）用户选择取款，并输入提取金额，该数额必须在50～2000之间，50的倍数5）ATM系统通知账户所在的主银行系统，传递账号和取款金额，并接受返回的确认信息和账户余额6）ATM系统发放现金、卡，并打印收据7）ATM将事务记入日志对“取款”用例的完整描述（续）备选事件流：2a：该卡不能在此ATM机上使用3a：密码不正确3b：用户没有及时输入密码4a：金额不是50的倍数，或不在指定范围5a：主机死机或网络瘫痪5b：账户余额不足发生频率：一天1000次“借出图书”的用例描述用例名称借出图书参与者图书管理员（主要参与者），读者（次要参与者）假设图书馆是开架借阅，读者总是找到书后办理借书手续，因此，借书不需要验证库存，而且每本书都是可识别的。前置条件图书管理员已被识别和授权后置条件存储借书记录，更新库存数量，所借图书状态为出借主事件流1．图书管理员将读者借书卡提供给系统；2．系统验证读者身份和借书条件；3．图书管理员将读者所借图书输入系统；4．系统记录借书信息，并且修改图书的状态和此种书的可借数量；5．系统累加读者的借书数量；6．重复3-5，直到图书管理员确认全部图书登记完毕；7．系统打印借书清单，交易成功完成。备选事件流2a．非法读者

1．系统提示读者身份错误，用例结束2b．读者借书数已达限额

1．系统提示读者已达结束限额，用例结束2c．读者有过期未还书籍

1．系统提示读者应归还的书籍列表和到期日，用例结束5a．读者借书数已达限额

1．系统提示，并要求结束输入

2．图书管理员确认借书完成5b．读者有该书的预定记录

1.删除该书的预定信息5、用例描述的双列格式用例名称归还图书参与者图书管理员（主要参与者），读者（次要参与者）假设因为每本书是可识别的，所以还书不需要验证读者前置条件图书管理员已被识别和授权后置条件修改借书记录，更新库存数量，修改图书状态为可借主事件流1．图书管理员将图书提供给系统；5．图书管理员重复步骤1，直到退出2．系统根据借书记录验证图书信息；3．系统提供借阅该书的读者信息；4．系统修改借书记录，更新该书的图书状态及此种书的可借数量；每个用例可绘制系统级顺序图纯文本的用例描述直观性较差使用UML中的顺序图可以图形化地表现出参与者和系统之间的交互较为合理的用例规格说明1用例名称：预定房间涉及的参与者：酒店前台描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。前置条件：前台工作人员必须已经登录到这个系统后置条件：预定信息正确的记录到系统中正常事件流：1)前台人员向系统提供需要预定房间的类型、时间和预定天数。2)系统确认有相应档次的空闲房间，并计算出总费用和定金。3)前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。4)系统记录旅客信息。5)前台人员确认已经交纳定金。6)系统记录房间已经预定，工作完成。备选事件流：2a.没有指定类型的空闲房间,可以转到