资源预览内容
第1页 / 共31页
第2页 / 共31页
第3页 / 共31页
第4页 / 共31页
第5页 / 共31页
第6页 / 共31页
第7页 / 共31页
第8页 / 共31页
第9页 / 共31页
第10页 / 共31页
亲,该文档总共31页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
UML面向对象建模基础,用例图,知识图谱,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,现代需求实践,共性:站在用户的角度看待系统、定义系统 ;使用用户能够看懂的语言来表述,用例驱动开发过程,知名的“用例驱动”的开发过程有两个,一个就是重型的RUP,另一个则是“离地1000公尺”的ICONIX 在这些开发过程中,开发人员首先捕获客户的需求,并以用例的形式组织成用例模型。然后分析并设计系统来满足这些用例,因此在用例模型之后就是分析模型,接着是设计模型和实施模型。在实现了整个系统之后,还将根据用例模型设计出测试模型来对系统进行验证 这些模型之间并不是线性转变的,它们是一个迭代、增量的开发过程。也就是在整个项目开发周期中,将会多次经过这五个模型的迭代,每次都将越来越精化,参与者,参与者是为了完成一个事件而与系统交互的实体,是用户相对系统而言所演的角色 参与者不仅可以由人承担,还可以是其它系统、硬件设备、甚至是时钟 1)其它系统:当系统需要与其它系统交互时,如ATM柜员机系统中,银行后台系统就是一个参与者; 2)硬件设备:如果系统需要与硬件设备交互时,如在开发IC卡门禁系统时,IC卡读写 器就是一个参与者; 3)时钟:当系统需要定时触发 时,时钟就是参与者,用例,用例实例是在系统中执行的一系列动作,这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例 用例是由一组用例实例组成的,用例实例也就是常说的“使用场景”,就是用户使用系统的一个实际的、特定的场景 用例应该给参与者带来可见的价值,这点十分关键,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,阅读用例图,用例图的组成元素,图中的元素包括:参与者、用例、一个方框和一些表示关系的连接线 所有的用例都位于方框之内,该方框称为“系统边界” 参与者与用例的关系:在参与者和用例之间的关联是用一根带箭头的线来表示的 用例之间的关系: 1)包含关系 2)扩展关系 3)泛化关系,包含与扩展关系,被包含的用例(此例中的检查座位详情)不是孤立存在的,它仅作为某些包含它的更大的基用例(此例中的预订座位、安排座位)的一部分出现 基用例是可以独立于扩展用例存在的,只是在特定的条件下,它的行为可以被另一个用例的行为所扩展,泛化关系,可以用来表示参与者与参与者之间,用例与用例之间的特殊/一般化关系,读图小结,这张用例图首先定义了三个基用例:预订座位、安排座位和处理结账 客户通过Internet启动“预订座位”用例,在“预订座位”用例的执行过程中,将“检查座位信息”(被包含用例),如果没有空闲的座位或满意的座位,可以选择进入等候队列,这样就将启动扩展用例“处理等候队列”。 总台服务员在客户到棋牌馆时,启动“安排座位”用例,在执行过程中,将启动被包含用例“检查座位信息”。 当客户要离开棋牌馆时,总台服务员将启动“处理结账”用例,并且定义了两种“收款”用例,一个是“处理现金结账”,另一个是“处理银行卡结账”,而后一个用例将通过与外部系统“银联POS系统”交互来完成。,用例描述,用例描述的是一个系统做什么(what)的信息,并不说明怎么做(how),怎么做是设计模型的事 事件流:,用例描述模板,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,用例图的绘制流程,记录需求特性表,识别参与者,已有的上下文关系图(表示系统范围)及其他相关模型:它们描述了系统与外部系统的边界,从这些图中可以寻找出与系统有交互关系的外部实体。 项目相关人员分析:对项目的相关人员进行分析,就能够决定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档(如会谈备忘录等) 需求研讨会和联合应用开发会议的记录:这些会议的参与者通常是很重要的,因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。 当前过程和系统的培训指南及用户手册:这些东西中经常会有潜在参与者。,合并需求获得用例,绘制用例图,细化用例描述搭框架,1.用例名称:新增书籍信息(UC01) 2.简要说明:录入新购书籍信息,并自动存储建档。 3.事件流: 3.1 基本事件流 3.2 扩展事件流 4.非功能需求 5.前置条件:用户进入图书管理系统。 6.后置条件:完成新书信息的存储建档。 7.扩展点:无 8.优先级:最高(满意度 5,不满意度5),细化用例描述填血肉, 3.事件流: 3.1 基本事件流 1)图书管理员向系统发出“新增书籍信息”请求; 2)系统要求图书管理员选择要新增的书籍是计算机类还 是非计算机类; 3)图书管理员做出选择后,显示相应界面,让图书管理 员输入信息,并自动根据书号规则生成书号; 4)图书管理员输入书籍的相关信息,包括:书名、作者、 出版社、ISBN号、开本、页数、定价、是否有CDROM; 5)系统确认输入的信息中书名未有重名; 6)系统将所输入的信息存储建档。 3.2 扩展事件流 5a)如果输入的书名有重名现象,则显示出重名 的书籍,并要求图书管理选择修改书名或取消输入; 5a1)图书管理员选择取消输入,则结束用例,不做存储建档工作; 5a2)图书管理员选择修改书名后,转到5) 4.非功能需求:无特殊要求 ,编写要点,使用简单的语法:主语明确,语义易于理解; 明确写出“谁控制球”:也就是在事件流描述中,让读者直观地了解是参与者在控制还是系统在控制; 从俯视的角度来编写:指出参与者的动作,以及系统的响应,也就是从第三者观察的角度; 显示过程向前推移:也就是第一步都有前进的感(例如,用户按下tab键作为一个事件就是不合适的); 显示参与者的意图而非动作(如果只描述了动作,人们不能够很容易地直接从事件流描述中理解用例);,编写要点,包括“合理的活动集”(带数据的请求、系统确认、更改内部、返回结果); 用“确认”而非“检查是否”,例如“系统确认所输入的信息中书名未有重名”; 可选择地提及时间限制; 采用“用户让系统A与系统B交互”的习惯用语; 采用“循环执行步骤x到y,直到条件满足”的习惯用语。,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,用例模型的运用方法,增量开发的用例模型 模型的无缝转换,建模要点,构建结构良好的用例: 1)为系统和部分系统中单个的、可标识和合理的原子行为命名; 2)将公共的行为抽取出来,放到一个被包含用例中,再将它include进来; 3)对于变化部分,将其抽取出来,放到一个扩展用例(用extent连接)中; 4)清晰地描述事件流,使得读者能够轻而易举地理解 构建结构良好的用例图:摆放元素时,应该避免交叉线的出现 ;对于语义上接近的行为和角色,最好使它们在物理上也更加接近; 根据系统实际情况控制粒度,Agenda,用例和用例驱动开发 如何阅读用例图 如何绘制用例图 用例图应用说明 本章小结,本章小结,首先从三种现代需求技术开始,引入了用例驱动开发过程的方法,并且详细地阐述了参与者和用例的概念 结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法,包括系统边界、包含关系、扩展关系以及泛化关系,并在此基础上介绍了用例描述的方法、格式及相关的要点 绘制方法:从记录需求到识别参与者、合并需求生成用例到最后的细化用例描述,进行了详尽的描述与说明 阐述了增量开发的用例模型、模型元素的无缝转换这两个重要观点,
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号