chapter06plus

上传人:sx****84 文档编号:242977701 上传时间:2024-09-13 格式:PPT 页数:80 大小:846KB
返回 下载 相关 举报
chapter06plus_第1页
第1页 / 共80页
chapter06plus_第2页
第2页 / 共80页
chapter06plus_第3页
第3页 / 共80页
点击查看更多>>
资源描述
,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,郑州大学软件学院,Software School, Zhengzhou University,2024/9/13,UML,系统分析与设计,UML-System Analysis & Design,1,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),2,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),3,Review,用例图定义,由参与者(,Actor,)、用例(,Use Case,)以及它们之间的关系构成的用于描述系统功能的动态模型图称为用例图。,参与者,用例,关系,4,Review,参与者(,Actor,),参与者是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。,参与者可以代表人或者事物,但是参与者不是人或者事物本身,而是其所扮演的,角色,。,参与者名称一般是,名词,或者,名词短语,,不能用动词。例如,参与者名称可以是刷卡子系统,但是不能是刷卡。,5,Review,用例(,Use case,),用例(,Use Case,)是参与者(角色)可以感受到的系统服务或功能单元。,任何用例都不能在缺少参与者的情况下独立存在。同样,任何参与者也必须要有与之关联的用例,所以识别用例的最好方法就是从分析系统参与者开始。,用例名称一般是动词,+,宾语。,6,关系,关联,泛化,包含,扩展,7,关联关系表示参与者和用例之间的通信。,用例与其参与者之间的关联关系用带箭头的直线表示。,用例与其参与者之间的关联,任何用例都不能在缺少参与者的情况下存在;任何参与者也必须要有与之关联的用例。,8,用例与用例之间的关系,泛化,包含,扩展,用例除了与其参与者发生关联外,用例之间具有多种关系,这些关系包括包含关系、扩展关系和泛化关系等。,9,如果系统中一个或多个用例是某个一般用例的特殊化时,就需要使用用例的泛化关系。,在,UML,中,用例泛化与其他泛化关系的表示法相同,用一个三角箭头从子用例指向父用例。,用例与用例之间的关系,泛化关系,10,用例与用例之间的关系,泛化关系,11,泛化,同一业务目的不同技术实现,用例与用例之间的关系,泛化关系,12,用例与用例之间的关系,包含关系,13,用例与用例之间的关系,包含关系,14,用例与用例之间的关系,包含关系,包含关系把几个用例的,公共步骤,分离成一个单独的被包含用例。,15,被包含用例称作提供者用例(基本用例),包含用例称作客户用例,提供者用例提供功能给客户使用。,用例与用例之间的关系,包含关系,16,包含关系误用,某些步骤在多个用例重复出现,且单独形成价值,17,用例与用例之间的关系,包含关系,18,用例与用例之间的关系,包含关系,19,用例与用例之间的关系,扩展关系,20,用例与用例之间的关系,扩展关系,扩展关系是把,新的行为插入,到已有用例中的方法。一个用例也可以被定义为基础用例的增量扩展,这称作扩展关系,;,21,在,UML,中,扩展关系表示为虚线箭头加,字样,箭头指向被扩展的用例(即基础用例)。,基础用例的扩展增加了原有的语义,用例与用例之间的关系,扩展关系,22,扩展关系误用,23,基础用例不必知道扩展用例的任何细节,它仅为其提供扩展点。,基础用例即使没有扩展用例也是完整的。,只有特定的条件发生,扩展用例才被执行。,扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的方法。,用例与用例之间的关系,扩展关系,24,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),25,用例的粒度,指的是用例所包含的系统服务或功能单元的多少。,用例的粒度越大,用例包含的功能越多,反之则包含的功能越少。,用例粒度,26,用例粒度,比较下列两图用例的粒度,27,如果用例的粒度很,小,,得到的用例数就会,太多。反之,,如果用例的粒度很,大,,那么,得到的,用例数就会很,少,。,如果,用例数目过多,会,造成用例模型过大,和引入设计困难大大提高。 如果,用例数目,过,少,会,造成用例的粒度太大,不便于进一步,的充分,分析,用例粒度,28,用例粒度,错误一:,把步骤当用例,29,用例粒度,错误二:,把系统活动当用例,30,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),31,用例图只是在总体上大致描述了系统所提供的各种服务,让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息,以便让其他人对于整个系统有一个更加详细地了解,这些信息包含在用例规约之中。,用例模型指的也不仅仅是用例图,而是由用例图和用例的详细描述,用例规约所组成的。,用例规约,32,用例图是骨架,而用例规约则是其内在的肉,33,高屋建瓴与细致入微相得益彰,图形,in Rose,文本,in Word,34,用例规约包含以下内容:,1,简要说明,:,对用例作用和目的的简要描述。,2,事件流,:,事件流包括基本流和备选流。基本流描述的是用例的基本流程,是指用例“正常”运行时的场景。,3,用例场景,:,同一个用例在实际执行的时候会有很多不同的情况发生,称之为用例场景,也可以说用例场景就是用例的实例。,4,特殊需求,:,特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求,包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。,5,前置条件,:,执行用例之前系统必须所处的状态。例如,前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。,6,后置条件,:,用例执行完毕后系统可能处于的一组状态。例如,要求在某个用例执行完后,必须执行另一个用例。,用例规约,35,事件流,说明用例如何开始和结束。只说明属于该用例的事件,而不是发生在其他用例中或系统外部的事件。,避免不明确的术语,如“例如”、“等等”和“信息”,36,事件流,在事件流里要对事件流进行结构化说明,基本事件流,描述每个情节的行为者,:,目标语句对的顺序,假设之前的每一步都是成功的,备选事件流,异常情况,对于异常中的异常,用更长的前缀标记更深一层的失败情节,37,非功能需求,(URPS),可用性(,Usability,),可靠性(,Reliability,),性能(,Performance,),可支持性(,Supportability,),设计约束,用,Oracle,数据库平台,用,PB,开发,软件必须符合,ISO,标准,本质上不是需求,只是从商业、行政、技术上的约束,特殊需求,38,前置、后置条件,前置条件约束在用例开始前系统的状态,把它们看做是看门人,它阻止参与者触发该用例直到满足所有条件,说明在用例触发之前什么必须为真,后置条件约束用例执行后系统的状态,用例执行后什么必须为真,对于有多个事件流的用例,则应该有多个后置条件,39,术语是不同专业领域中的专用语,非本专业的人不能理解,为便于不同的人员理解和交流,需要对术语进行解释和定义。,术语表的每一项都定义了一个术语,定义可长可短;,术语表可以让查看软件开发产品的人觉得行话不再神秘。,词汇表,40,词汇表,41,用例规约示例,用例编号,UC03,用例名称,记录时间日志,用例概述,开发人员可以随时记录自己的时间,提供“开始计时”、“暂停计时”、“停止计时”等功能,在停止时,填入任务编号(在线则选择)、工作关键字(以逗号分隔的多个),自动生成开始时间、暂停时间、停止时间、总时长、有效时长(总时长,-,中断时长)。,主参与者,开发人员,前置条件,用户进入“记录时间日志”程序,后置条件,将本次时间日志存入数据库,基本事件流,步骤,活动,1,系统显示“开始”、“暂停”和“停止”按钮,但仅“开始”可用,2,用户点击“开始”,系统记录开始时间,并将“开始”置为不可用,使“暂停”和“停止”按钮可用,3,用户点击“停止”按钮,系统记录停止时间,并统计暂时时间、暂停次数、总时长、有效时长,并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后,点击确定,用例完成。,扩展事件流,3a,在此期间,若用户点击“暂停”按钮,系统则记录暂停开始时间,并使暂停次数增加,1,次,并使“暂停”按钮变为“恢复”,使“停用”按钮不可用,3a1,当用户点击“恢复”按钮,用当前时间减去暂停开始时间得到本次暂停时间,并累加到“暂停时间”时间中,并使“恢复”按钮变为“暂停”,使“停用”按钮恢复可用,规则与约束,时间记录程序应以离线式工作,该程序会自动连接服务器,完成时间日志上传的工作,如果未能连接服务器,则在本机暂存时间日志,42,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),43,基于用例的需求分析过程,1.,获取原始需求,2.,开发一个可以理解的需求,2.1,识别参与者,2.2,识别用例,2.3,构建用例图,3,详细、完整地描述需求,进行用例阐述,4,重构用例模型,4.1,识别用例间的关系,4.2,对用例进行组织和分包,44,基于用例的需求分析过程,1.,获取原始需求,2.,开发一个可以理解的需求,2.1,识别参与者,2.2,识别用例,2.3,构建用例图,3.,详细、完整地描述需求,进行用例阐述,4.,重构用例模型,4.1,识别用例间的关系,4.2,对用例进行组织和分包,45,1,获取原始需求,技巧,描述,实地观察,直接观察个人工作的情况,以发现现存的实践方式和问题,访谈,从个人处收集特定信息,特定群体调查,对一组人员进行调查,以便了解工作态度和共同看法,问卷调查,收集详细数据和统计意义上比较重要的数据,用户指导,让最终用户告诉你,他们是如何操作系统的,原型制作,模拟一个无法直接测试的系统,统计版本,使用具有统计功能的应用程序来记录用户完成任务的方式,46,获取需求:考勤卡应用程序,初次访谈记录,开发者,:谁将使用这个应用程序?,客 户,:所有用它来记录可记帐以及不可记帐的工时的雇员,开发者,:现在考勤卡应用程序是什么样的?,客 户,:每半个月就用一个,Excel,表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。,开发者,:这个收费项目代码可以从什么地方得到?,开发者,:谁来管理收费项目代码?,客 户,:嗯,必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,47,基于用例的需求分析过程,1.,获取原始需求,2.,开发一个可以理解的需求,2.1,识别参与者,2.2,识别用例,2.3,构建用例图:确定参与者和用例之间的关系,3.,详细、完整地描述需求,进行用例阐述,4.,重构用例模型,4.1,识别用例间的关系,4.2,对用例进行组织和分包,48,2.1,识别参与者,谁使用系统的主要功能,谁改变系统的数据,谁从系统获取信息,谁需要系统的支持以完成日常工作任务,谁负责日常维护、管理并保证系统正常运行,系统需要应付(处理)那些硬设备,系统需要和那些外部系统交互,谁(或什么)对系统运行产生的结果(值)感兴趣,时间、气温等内部外部条件,49,识别参与者:考勤卡系统,开发者,:谁将使用这个应用程序?,客 户,:所有用它来记录可记帐以及不可记帐的工时的,雇员,开发者,:现在考勤卡应用程序是什么样的?,客 户,:每半个月就用一个,Excel,表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。,开发者,:这个收费项目代码可以从什么地方得到?,开发者,:谁来管理收费项目代码?,客 户,:嗯,必要的时候由我,(业务经理),来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,50,参与者的泛化:责任重叠,Generalization, A generalization from an actor A to an actor B indicates that an instance of A can communicate with the same kinds of use-case instances as an instance of B,如系统中经理可以参加雇员的所有用例,51,泛化关系的误用,52,2.2,识别用例,关键词:价值,定义,一个用例定义,一组用例实例,用例实例是,系统执行,的,一系列动作,,这些动作将生成特定,参与者可观测,的,结果值,简单的说:参与者,使用系统,达到目标,53,识别用例:考勤卡系统,开发者,:谁将使用这个应用程序?,客 户,:所有用它来,记录可记帐以及不可记帐的工时,的,雇员,开发者,:现在考勤卡应用程序是什么样的?,客 户,:每半个月就用一个,Excel,表格来记录。每个雇员都将通过他的表格填好,然后用电子邮件发给我。这个表格相当标准:纵向是收费项目代码,横向是日期。雇员可以在每个条目上填写说明。,开发者,:这个收费项目代码可以从什么地方得到?,开发者,:谁来,管理收费项目代码,?,客 户,:嗯,必要的时候由我,(业务经理),来添加这个代码。而每个经理总会告诉他的下属应该填写什么。,54,用例要点,结果值,用例是有意义的目标,系统执行,结果值由系统生成,由参与者观测,业务语言、用户观点,一组用例实例,用例的粒度,55,2.3,构建用例图,56,基于用例的需求分析过程,1.,获取原始需求,2.,开发一个可以理解的需求,2.1,识别参与者,2.2,识别用例,2.3,构建用例图,3,详细、完整地描述需求,进行用例阐述,4,重构用例模型,4.1,识别用例间的关系,4.2,对用例进行组织和分包,57,3,进行用例阐述:写用例规约,用例规约用来描述用例的,不是用例图,58,基于用例的需求分析过程,1.,获取原始需求,2.,开发一个可以理解的需求,2.1,识别参与者,2.2,识别用例,2.3,构建用例图,3,详细、完整地描述需求,进行用例阐述,4,重构用例模型,4.1,识别用例间的关系,4.2,对用例进行组织和分包,59,4.1,用例关系,Extend,Include,Generalization,60,通过关系整理文档,Extend,分离扩展路径,Include,提取公共步骤,便于复用,Generalization,同一业务目的的不同技术实现,61,4.2,用例进行分类,用例和开发周期,开发周期是围绕用例的需求来组织的,一个开发周期要被指派一个到多个用例,如果完全版本的用例在一个开发周期中处理起来太复杂的话,那就采用简化版本的用例,开发周期,开发周期,开发周期,用例,A,-,简化版本,用例,A,-,完整版本,用例,B,用例,C,62,在开发过程中,尤其是在递增开发过程中,最好按照实现的优先级给系统需求分级,然后给每个用例打分,表示紧急程度。,有效的打分技术是交通灯,系统用例的优先级,绿色的用例必须在当前的开发过程中实现,否则就意味着项目没有达到其最低目标;,黄色的用例在当前的开发过程中是可选的,只有在完成了绿色的用例后才能完成它;,红色的用例即使时间允许,也不在当前的开发过程中实现。,63,用例的组织,对用例进行分包,让用例图能够更为清晰地表现出系统的业务逻辑关系和层次,对系统进行模块的分割,这将影响到今后的开发和系统的最终表现形式,64,用例的组织,常见的分包方式,按参与者分包,按主题分包,按开发团队分包,按发布情况分包,可以先按主题分包,主题内再按开发团队和发布情况分包,65,重点内容:,Review,用例粒度,用例规约,使用,Rose,创建用例图的步骤说明,实例,第,6,章 用例图,(补充内容),66,“企业进、存、销管理系统” 功能性需求包括以下内容:,(,1,)采购员根据生产原料的使用情况判断采购用品,对需要订购产品信息统计订货的,并制作产品订单。最后根据订单进行采购活动。,(,2,)仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息,包括:供应商信息、产品信息。仓库管理员每天对产品进行一次盘点,当发现库存产品有损坏时,及时处理报损信息。当产品生产后,将产品进行入库。当产品销售后时,产品进行出库处理。,(,3,)统计人员负责统计分析管理,包括:查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息,并制作报表。统计分析员使用系统的统计分析功能,了解产品信息、销售信息、供应商信息、库存信息。,(,4,)在销售员为客户提供售货服务时,接受客户购买产品,根据系统的定价计算出产品的总价,客户付款,系统自动保存客户购买记录。,(,5,)系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。,1,、需求分析,实例,67,(,1,)销售员:为客户客提供销售产品的服务。,(,2,)仓库管理员:负责库存产品的管理活动。,(,3,)采购员:负责企业生产原料的订购。,(,4,)会计:负责企业经营状况的统计。,(,5,)系统管理员:负责企业员工信息管理、供应商信息管理以及系统维护等。,2,、识别参与者,实例,68,销售员能够通过该系统进行销售商品活动。首先登录系统,验证身份成功后,获取商品信息,然后将销售信息更新,最后对客户进行商品销售。,3,、构建用例模型,销售员用例图,实例,69,仓库管理员能够通过该系统进行如下活动:,(,1,)处理盘点,每天需要对库存产品信息进行盘点。,(,3,)产品入库。当产品生产后,将产品进行入库。,(,4,)产品出库。当产品销售发货后,进行出库处理。,(,5,)管理设置。仓库管理员负责供应商信息、产品基本信息的管理设置。,3,、构建用例模型,仓库管理员用例图,实例,70,采购员能够通过该系统进行订货管理活动。采购员首先根据经营情况统计所缺的生产资料,根据需要制定出订单。,3,、构建用例模型,采购员用例图,实例,71,会计负责产品的统计分析管理,它能够通过该系统进行如下活动:,(,1,)查询基本信息。会计能够查询产品的基本信息,根据产品的基本信息,制定出相应的方案。,(,2,)查询销售信息。会计根据销售情况汇总后交销售部制定合理的销售方案。,(,3,)查询供应商信息。会计能够查询供应商信息。,(,4,)查询缺货信息。会计能够查询缺货信息。,(,5,)查询报损信息。会计能够查询报损信息。,3,、构建用例模型,会计用例图,实例,72,系统管理员能够通过该系统进行如下活动:,(,1,)维护员工信息。系统管理员能够维护企业员工的信息,如添加员工、删除员工和修改员工信息等。,(,2,)维护供应商信息。系统管理员能够维护供应商的信息,如添加供应商、删除供应商和修改供应商信息等。,(,3,)系统设置。系统管理员能够根据一些需要进行必要的系统设置。,3,、构建用例模型,系统管理员用例图,实例,73,课堂练习,“,学生信息管理系统”,在每个新学年开始的时候都会有新生入学。这时系统的管理人员可以通过系统将这些新生的学籍、年龄、家庭住址、性别、学生证号、身份证号等基本信息存入数据库。在日常的管理中,系统管理员还可以对所有学生的基本信息进行查询、修改、删除等操作。校领导可以查询、修改全校学生的基本信息,教师可以在日常工作中查询、修改自己班里学生的基本信息。,学校的领导可以通过本系统了解每个班的任课教师、辅导员、学生、专业等班级基本信息。系统管理员可以进行查询班级基本信息、添加新班级、修改班级信息、删除班级等操作。,考试结束后,教师可以录入学生成绩,还可以对成绩进行修改和查询。学生可以查询成绩。,学生可以网上选课,可以通过系统看到课程的信息。每个学生每个学期的选课不得大于,6,门,如果已经选了,6,门课则不能选择新的课程。只有将已选的课程删除后才能再选。系统管理员负责修改、增加、删除选修课程。,每个用户登陆系统,都需要一个账号,这就需要系统管理员对用户账户进行管理。,74,需求分析,1.,学生信息管理模块,学生信息管理模块主要用来实现系统管理员、教师、校领导等对学生基本信息的管理。系统管理员登录后可以对学生的基本信息进行增加、删除、修改和查询等操作;教师的校领导登录后可以对学生信息进行查询和修改操作。,2.,班级信息管理模块,班级信息管理模块主要用来实现系统管理员、校领导对班级基本信息的管理。系统管理员登录后可以对班级基本信息进行增加、删除、修改和查询等操作;校领导登录后可以对学生信息进行查询操作。,3.,成绩管理模块,成绩管理模块主要用于实现教师对学生考试成绩的管理以及学生对考试成绩的查询。教师登录后可以对学生成绩进行录入、删除、修改和查询等操作;学生登录后可以对成绩进行查询操作。,4.,网上选课模块,网上选课模块主要用于实现学生在网上了解并选择自己感兴趣的课程。,5.,账号管理模块,账号管理模块主要实现系统管理员对用户账号的管理。系统管理员可以对账号进行增加、删除、修改和查询等操作。,75,构建用例模型,1.,班级信息管理用例图,76,2.,成绩管理用例图,77,3.,网上选课用例图,78,4.,账号管理用例图,79,复习第,6,章内容,预习第,7,章;,书面作业:,上机实验作业:,作业,1,、简述用例规约包含的内容。,1,、,登录,下载实验要求、实验报告模板,,目录:,/UML(薛均晓)/上机实验/,2,、,完成实验报告并提交至,20,2.197.189.182,80,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 图纸专区 > 课件教案


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!