第3章(用例图)

第3章用例图,本章目标,理解需求分析与用例图之间的关系。掌握参与者、用例、关系的概念。学会通过分析需求画出用例图。,知识图谱,Agenda,软件需求过程如何阅读用例图如何绘制用例图用例图应用说明本章小结,Agenda,软件需求过程如何阅读用例图如何绘制用例图用例图应用说明本章小结,软件需求过程,传统方法,软件需求规约,用例分析法,面向对象的方法,软件生命周期,包括,用例驱动的开发过程,迭代、增量的开发过程,用例图,描述系统功能。,Agenda,用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结,阅读用例图,用例图的组成元素,参与者、用例、方框和连接线用例位于方框之内，该方框称为“系统边界”参与者与用例的关系：关联用例之间的关系,1）包含关系,2）扩展关系,3）泛化关系,参与者,1）人2）其它系统：当系统需要与其它系统交互时；3）硬件设备：如果系统需要与硬件设备交互时，4）时钟：当系统需要定时触发时，时钟就是参与者,为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色。,概念,参与者的身份,参与者的表示方法,如何发现系统的参与者,谁使用系统？谁安装系统、维护系统？谁启动系统、关闭系统？谁从系统中获取信息，谁提供信息给系统？在系统交互中，谁扮演了什么角色？系统会与哪些其他系统相关联？,参与者,例1：客户给销售员发来传真订货，销售员下班前将当日订货单汇总输入系统。,答案：销售员,问题：谁是系统的Actor？,参与者,如何发现系统的参与者,例2：寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。,问题：谁是寻呼台系统的Actor?答案：用户，气温，时间都是Actor。,参与者,如何发现系统的参与者,参与者之间的关系,参与者,参与者,参与者之间的关系,公司管理系统用例图,泛化后的公司管理系统用例图,系统边界,系统与系统之间的界限。系统系统环境在Rose中并不画出系统边界。系统边界决定了参与者。,用例,是对系统中执行的一系列动作的描述，这些动作将生成特定参与者可见的价值结果。,概念,识别用例,参与者希望系统提供什么功能；系统是否存储和检索信息；当系统改变状态时，是否通知参与者；是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。,用例,从分析系统的参与者开始，考虑每个参与者是怎样使用系统。,识别用例,用例,例1：Email客户端（如:outlookexpress），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。,识别用例,用例,例2：一个论坛类的应用，用户可以提问，别人来回答，如果有自己提的问题被解答的话，就给回答者发一份邮件表示感谢。,论坛类应用的用例图,如何判断一个用例是否是一个优秀的用例呢？,用例,用例是否描述了应该做什么，而不是如何做？用例的描述是否采取了参与者的视点？用例是否对参与者有价值？用例描述的时间流是否是一个完整场景？是否所有的参与者、用例都有相应的关联用例或关联参与者？,用例,用例的粒度,用例所包含的系统服务或功能单元的多少。,用例规约,对每一个用例的详细描述信息，以便于其他人对整个系统有一个更加详细地了解。,用例规约的内容,（1）简要说明（2）前置条件,（3）基本事件流（4）其他事件流（5）异常事件流,（6）后置条件,用例,事件流,例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。,提款基本事件流基本流步骤1：用户插入信用卡基本流步骤2：输入密码基本流步骤3：输入提款金额基本流步骤4：提取现金基本流步骤5：退出系统，取回信用卡,用例,提款备选事件流其他流一：用户可以在基本流中的任何一步选择退出，转至基本流骤5。其他流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。其他流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。,例：将银行自动取款机(ATM)系统中的“提款”用例用事件流表述。,用例,事件流,用例规约模板,包含关系扩展关系泛化关系,用例之间的关系,包含关系,用例之间的关系,一个用例的行为包含另一个用例的行为。,包含关系,用例之间的关系,如何处理包含关系？（1）多个用例用到同一段的行为，则抽取共同的行为；,用例之间的关系,（2）某一用例的功能过多，则抽象出一段事件流。,包含关系,如何处理包含关系？,用例之间的关系,包含关系,用例之间的关系,扩展关系,允许一个用例（可选）扩展另一个用例提供的功能。,用例之间的关系,扩展关系,用例之间的关系,扩展关系,包含关系与扩展关系的区别,用例之间的关系,扩展关系,扩展用例是可选的，而包含用例则不是。扩展用例的执行需要满足某种条件，而包含用例不需要。扩展用例的执行会改变基础用例的行为，而包含用例不会。,泛化关系,可以用来表示用例与用例之间的特殊/一般化关系。,用例之间的关系,泛化关系,举例（一）：,用例之间的关系,举例（二）：,用例之间的关系,泛化关系,读图小结,读图小结,这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账。“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。,Agenda,用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结,用例图的绘制流程,案例分析,HNS是一所以培养软件开发人才为目标的高等院校，为适应IT产业发展对技术人才的需求，近年来扩大了招生规模，随着在校学生的增加，学院计划改善包括图书馆在内的各项教学设施，拟开发图书管理系统使其可以满足学生的要求。,任务：请分析该系统的需求，确定系统中的参与者和主要用例，并画出用例视图。,问题,（1）读者需要借书、还书；（2）读者需要预约书籍、也可以取消预约；（3）管理员根据读者要求提供服务；（4）管理员必须维护读者信息；（5）管理员必须维护书籍信息。,需求分析,案例分析,确定系统参与者,管理员,案例分析,读者,确定系统用例,案例分析,绘制用例图,图书管理系统顶层用例图,案例分析,读者信息管理用例图,绘制用例图,案例分析,书籍信息管理用例图,绘制用例图,案例分析,图书馆业务用例图,案例分析,绘制用例图,信息查询用例图,案例分析,绘制用例图,细化用例描述搭框架,1.用例名称：新增书籍（UC01）2.简要说明：录入新购书籍信息，并自动存储建档。3.事件流：3.1基本事件流3.2扩展事件流4.非功能需求5.前置条件：用户进入图书管理系统。6.后置条件：完成新书信息的存储建档。7.扩展点：无8.优先级：最高,案例分析,细化用例描述填血肉,3.事件流3.1基本事件流1）管理员选择进入管理界面，用例开始。2）系统提示输入管理员密码。3）管理员输入密码。4）系统验证密码。A1:密码错误。5）进入管理界面，系统显示目前所建立的全部书籍信息。6）管理员选择添加书籍。7）系统提示输入新书籍信息8）管理员输入书籍信息。9）系统验证是否和已有书籍冲突。A2:有冲突。10）系统添加新书籍，提示添加书籍成功。11）系统重新进入管理主界面，显示所有书籍信息。12）用例结束。,扩展事件流A1:密码错误1）系统提示再次输入。2）用户确认。3）三次错误，拒绝再次访问。4）否则进入添加书籍事件流第5步。A2:有冲突1）系统提示冲突，显示冲突课程信息。2）用户重新输入。3）继续验证直到无冲突。4）进入添加书籍事件流第10步。,细化用例描述填血肉,编写要点,使用简单的语法；明确写出“谁控制球”；从第三者观察的角度；显示过程向前推移；显示参与者的意图而非动作；,Agenda,用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结,用例图应用说明,建模要点,构建结构良好的用例：1）为系统和部分系统中单个的、可标识和合理的原子行为命名；2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来；3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中；4）清晰地描述事件流，使得读者能够轻而易举地理解5）摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；根据系统实际情况控制粒度,Agenda,用例和用例驱动开发如何阅读用例图如何绘制用例图用例图应用说明本章小结,本章小结,首先从传统的需求表述方法开始，引入了用例图表达系统需求的优越性。结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法，包括系统边界、包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及相关的要点。绘制方法：从记录需求到识别参与者、合并需求生成用例到最后的细化用例描述，进行了详尽的描述与说明。,1.对于一个电子商务网站而言，以下哪些不是合适的用例，指出并说明理由。,输入支付信息将商品放入购物车结账预订商品用户登录邮寄商品查看商品详情,答案：输入支付信息：太小邮寄商品：系统功能之外查看商品详情：太小,练习题,练习题,为了满足物业中介行业的信息化要求，甲公司基于详尽的需求调研与分析，准备研发一套符合市场需要的、实用的信息管理系统。主要将实现客户资料信息管理、客户委托（出租、出售、租赁、购买）信息管理、业务线索生成与管理、房源状态自动更新、权限管理、到期用户管理、房源组合查询等功能。该公司小王，通过多次的与潜在客户的交流与沟通，完成了最初的用例模型的开发，如图是一个用例模型的局部：,（1）但小李认为该模型不符合“用例建模”的思想，存在明显的错误。请用200字以内说明错误所在，并说明应该如何修改。,答案：1）主要错误：用例的分解太细，并没有遵从每个用例为用户传递一个有价值的结果的原则。在原设计中“打开房源信息页面”