1、第二章 需求建模,2.1 用例图,本章目标,理解用例图的概念和内容。 理解活动图的概念和内容。 能够使用用例图和活动图对一个简单的系统进行需求分析。,章节安排,2.1 用例图 2.2活动图,本节目标,理解需求分析与用例图之间的关系。 掌握参与者、用例、关系的概念。 学会通过分析需求画出用例图。任务 分析本章的项目引入中的系统的需求，确定系统中的参与者和主要用例，并画出用例视图。,案例描述,HNS是一所以培养软件开发人才为目标的高等院校，为适应IT产业发展对技术人才的需求，近年来扩大了招生规模，随着在校学生的增加，学院计划改善包括图书馆在内的各项教学设施，拟开发图书管理系统使其可以满足学生的要求
2、。,现实案例,建筑效果图 建筑规划图 建筑平面图,需求,需求是指系统必须符合的条件或具备的功能。 需求问题是引起软件项目的高风险率的最主要原因 缺乏需求 对需求的不正确理解 需求的不完整 需求的变化,需求建模,如何描述需求？ 图书管理系统的需求描述如下： 1新书入库：当图书馆新进一批新书时，图书管理员需要登记入库信息，并为每一本新书制作一个图书卡(书目条)。 2借阅者信息维护：包括两个方面的工作：一是新读者的办证操作，二是读者基本信息的维护工作。 3预约借书：当读者想借阅书不在时，可以通过预约的方式预定不在库的书籍。 4借书：根据借阅者提供的书目编号，办理借书手续。 5还书：根据借阅者归还书籍
3、的书目编号，办理归还手续。 6图书查询：读者在借书前，通过书目目录去查询所需书籍的书目编号。,需求建模,如何使用UML对需求建模呢？如图：,需求建模,使用UML对需求建模的优势？ 1、帮助项目人员按照实际情况对系统可视化。 2、对系统的描述一目了然，方便与用户的交流和沟通。 3、不易产生二义性，利于系统的分析和设计。,用例图,用例图是显示一组用例、参与者以及它们之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为 用例图常用来对需求建模，用例图是至关重要的，它的正确与否直接影响到客户对最终产品的满意度 用例图的内容： 参与者 用例 泛化、扩展
4、和包含关系,参与者（Actor),参与者( Actor) 是系统外部的一个人或物，它以某种方式参与了系统的执行过程。 参与者对系统而言总是外部的 参与者在系统的不同组成部分可能扮演不同的角色 参与者用一个人形的图案表示,识别参与者,客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。谁是系统的Actor？答案： 销售员,识别参与者,寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。这个叙述里，谁是寻呼台系统的Actor?用户？气温？时间？答案：用户，气温，时间都是Actor,识别参与者,商品销售系统。顾客通过网络下单之后
5、，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。有几个Actor？,答案： 顾客(商品销售系统)，商品销售系统(会计系统),参与者,使用以下问题有助于发现系统的参与者 谁使用系统？ 谁安装系统、维护系统？ 谁启动系统、关闭系统？ 谁从系统中获取信息，谁提供信息给系统？ 在系统交互中，谁扮演了什么角色？ 系统会与哪些其他系统相关联？,用例 (UseCase),用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。 参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 用例用实线的椭圆表示,用例,识别用例的最好办法就是从分析
6、系统的参与者开始，考虑每个参与者是怎样使用系统。 根据下面的一些问题来识别用例： 参与者希望系统提供什么功能； 系统是否存储和检索信息； 当系统改变状态时，是否通知参与者； 是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。,识别用例,Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。,识别用例,一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例,用例,如何判断一个用例是否是一个优秀的用例呢？ 用例是
7、否描述了应该做什么，而不是如何做？ 用例的描述是否采取了参与者的视点？ 用例是否对参与者有价值？ 用例描述的时间流是否是一个完整场景？ 是否所有的参与者、用例都有相应的关联用例或关联参与者？,用例与事件流,用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。 事件流可分为：基本事件流 、备选事件流,用例与事件流,银行自动取款机(ATM)系统中的“提款”用例可以用事件流表述如下,提款基本事件流基本流步骤1：用户插入信用卡基本流步骤2：输入密码基本流步骤3：输入提款金额基本流步骤4：提取现金基本流步骤5：退出系统，
8、取回信用卡,用例与事件流,提款备选事件流 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。,用例之间的关系,泛化关系包含关系扩展关系,用例之间的关系,泛化：同一业务目的的不同技术实现包含：提取公共交互，提高复用扩展：“冻结”基用例以保持稳定*通过关系提高用例复用,泛化(generalization),当多个用例共同拥有一种类似的结构和行为的
9、时候 我们可以将它们的共性抽象成为父用例，其他的用例 作为泛化关系中的子用例。,泛化(generalization),泛化举例（一）：,泛化(generalization),泛化举例（二）：,包含(include),包含是指基本用例(base use case)会用到包含用例 (inclusion)，具体地讲，就是将包含用例的事件流 插入到基础用例的事件流中。包含用例是可重用的 用例多个用例的公共用例。,包含(include),包含(include),包含举例（一）：,包含(include),包含举例（二）：,扩展(extend),将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例
10、中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。,扩展(extend),扩展(extend),扩展举例（一）：,扩展(extend),扩展举例（二）：,用例之间的关系,包含用例与扩展用例的区别 相对于基础用例，扩展用例是可选的，而包含用例则不是。 如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。 扩展用例的执行需要满足某种条件，而包含用例不需要。 扩展用例的执行会改变基础用例的行为，而包含用例不会。,任务解决,系统中的主要活动，如下： 读者需要借书籍，需要还书籍。 读者可以预约书籍，也可以撤消预约。 管理员根据读者要求提供服务。 管理员可以添加、修改、删除读者。 管理员可以添加、修改、删除书籍。,任务解决,1确定系统参与者 管理员和读者 2确定系统用例。 3使用Rational Rose绘制用例图。,读者信息管理用例图的绘制,任务解决,任务解决,书籍信息管理用例图的绘制,任务解决,图书馆业务用例图的绘制,任务解决,信息查询用例图的绘制,小结,用例图是显示一组用例、参与者以及它们之间关系的图。 用例图包括以下三方面的内容。 参与者 用例 泛化、包含和扩展关系 事件流描述了用例的细节内容,
