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