资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件体系结构,第三章,用例图,用例图,内容与目标,需求分析与用例图,用例图概念,构成要素,重要元素,重要关系,用例描述,创建用例图,需求分析与用例图,需求的概念,需求：系统必须满足的条件或具备的能力,Robert Grady,软件质量准则,“,FURPS,”,功能性（,Functionality,）,使用性（,Usability,）,可靠性（,Reliability,）,性能（,Performance,）,可支持性（,Supportability,）,非功能性需求,需求分析与用例图,需求分析的重要性,在,Standish,Group,（美国专门从事跟踪,IT,项目成功或失败的权威机构）的报告中总结了导致项目失败的最重要的,8,大原因中，有,5,个与需求相关：,1,不完整的需求；,2,没有用户的介入；,3,不实际的客户期望；,4,需求和规范的变理；,5,提供了不再需要的。,需求分析与用例图,需求分析的困难,例：石头问题,客户描述：“,我要一块石头,”,差不多，但我要小一点的,很好，不过我要蓝色的,啊，没有那么小,咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！,需求分析与用例图,从哪里开始？,如何解决,用例,软件,从用例图开始,难捕获,易变,从用户视角看问题,合理的结构,用例,需求分析与用例图,从哪里开始,用例图,用例建模的,最主要功能,就是用来表达系统的功能性需求或行为；,用例建模可分为用例图和用例描述；,用例图,是由软件需求分析到最终实现的第一步，它描述人们如何使用一个系统，是外部参与者所能观察到的系统功能的模型图，该图呈现了一些参与者和一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模，用画图的方法来完成；,用例描述,用来详细描述用例图中每个用例，用文本文档来完成。,用例图概念,用例图,Use Case Diagram,用例图,由参与者,Actor,、用例,Use Case,以及它们之间的关系构成的用于描述系统功能的动态视图。,用例：,椭圆符号，用例的名称可放在椭圆的中心或椭圆下面的中间位置。,参与者：,人形符号，表示一个系统用户，。,关系：,使用带箭头或者不带箭头的线段来描述,箭头表示在这一关系中哪一方是对话的主动发起者,箭头所指方是对话的被动接受者,用例图概念,用例图的概念,注释,：在用例建模中，为了更加清楚的描述用例或者参与者，可使用注释。,用例图概念,重要元素,参与者,Actor,参与者是系统外部的一个实体，以某种方式参与用例的执行过程。是为了完成一个事件与系统进行交互的实体，是与系统交互作用的外部用户、进程或其他系统的理想化概念。,在,UML,中，参与者用名字写在下面的人形图标表示,参与者可以是任何事物,人、外部系统、硬件设备、时间等,用例图概念,重要元素,参与者,Actor,用例图概念,重要元素,参与者,Actor,用例图概念,构成,参与者,Actor,用例图概念,重要元素,参与者,Actor,参与者的识别原则,谁将使用该系统的主要功能,谁将需要该系统的支持以完成其工作,谁将需要安装、维护、管理该系统，以及保持该系统处于工作状态,系统需要处理哪些硬件设备,与该系统发生交互的是什么系统,谁或什么系统对本系统产生的结果感兴趣,用例图概念,重要元素,参与者,Actor,参与者的识别过程：考勤卡管理,开发者,：谁将使用这个应用程序？,客 户,：所有用它来记录考勤工时的雇员,开发者,：现在考勤卡应用程序是什么样的？,客 户,：每半个月就用一个,Excel,表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。,开发者,：这个项目需要和那些外部系统交互？,开发者,：谁来修改系统代码？,客 户,：嗯，必要的时候由我（业务经理）来修改系统代码。当然，我要按照人事经理的要求来操作,用例图概念,重要元素,参与者,Actor,参与者之间的关系,多个参与者之间可以具有关系,例：图书馆管理系统的借书者可,泛化,为两类：学生和老师；航空售票系统的客户可,泛化,为电话预定客户和网上预定客户,用例图概念,重要元素,参与者,Actor,参与者之间的关系,一般情况，参与者之间的关系可以用下图描述,用例图概念,重要元素,参与者,Actor,课堂练习：识别参与者,寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于,35,度，还要提醒用户注意防暑；,在这个叙述里，谁是寻呼台系统的,Actor,？用户？气温？时间？,用户,气象台,用例图概念,重要元素,用例,use case,用例是外部可见的系统功能单元。,用例是对一个系统或应用的一种单一的,使用方式,所作的描述。,用例的用途是，在不揭示系统内部构造的前提下定义系统的行为。,在,UML,中，用例用一个椭圆来表示，用例的名字可以写在椭圆的下方。,用例的名字是唯一的，,以区别于其它用例。,用例图概念,重要元素,用例,use case,用例的识别,用例图对整个系统的建模过程非常重要，在绘制系统用例图前，有许多工作需要做。,参与者描述了,“,谁来做,”,，而用例要描述的是,“,做什么,”,识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。,在识别用例的过程中也可能会发现新的参与者。,用例图概念,重要元素,用例,use case,用例的识别原则,特定参与者希望系统提供什么功能,系统是否存储和检索信息，如果是，由哪个参与者触发,当系统改变状态时，是否通知参与者,是否存在影响系统的外部事件,哪个参与者通知系统这些事件,用例图概念,重要元素,用例,use case,用例的识别,具体可以通过,查找事件,的方式来识别用例：,主语谓语宾语,已被识别出来的参与者,动作,动词涉及的目标,读者,借阅,书籍,用例图概念,重要元素,用例,use case,用例的识别过程：考勤卡管理,开发者,：谁将使用这个应用程序？,客 户,：所有用它来记录考勤工时的,雇员,开发者,：现在考勤卡应用程序是什么样的？,客 户,：每半个月就用一个,Excel,表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。,开发者,：这个项目需要和那些外部系统交互？,开发者,：谁来修改系统代码？,客 户,：嗯，必要的时候由,我（业务经理）,来修改系统。当然，我要按照人事经理的要求来操作,用例图概念,重要元素,用例,use case,用例的识别,用例的识别顺序是参与者,事件,用例,用例必须是由系统处理的工作，结果由系统生成,用例是从用户视角看问题，而不是系统视角,用例命名格式是“动词,+,宾语”，同时应使用用户词汇，而不是技术词汇,如：发票，商品，洗衣机,而不是：记录，字段，,COM,，,C+,等,用例图概念,重要元素,用例,use case,课堂练习：识别用例,Email,客户端（如：,outlook express,），,A,在北京发邮件给上海的,B,，系统提醒,B,有,“,新邮件,”,，从而,B,收邮件,收件人,发件人,发邮件,收邮件,邮件,邮箱系统,提醒新邮件,用例图概念,重要元素,用例,use case,用例的粒度,用例的粒度,指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。,如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。,如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。,最常犯错误：粒度过细，陷入功能分解,过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,用例图概念,重要关系,参与者与用例之间的关系,关联关系,关联关系表示参与者和用例之间的通信。,用例与其参与者之间的关联关系用带箭头的直线表示。,任何用例都不能在缺少参与者的情况下存在；任何参与者也必须要有与之关联的用例。,用例图概念,重要关系,用例之间的关系,用例除了与其参与者发生关联外，用例之间具有多种关系，这些关系包括,包含关系、扩展关系和泛化关系,等。,泛化,包含,扩展,用例图概念,重要关系,用例之间的关系,泛化关系,如果系统中一个或多个用例是某个一般用例的,特殊化,时，就需要使用用例的泛化关系。,在,UML,中，用例泛化与其他泛化关系的表示法相同，用一个,三角箭头,从子用例指向父用例。,用例图概念,重要关系,用例之间的关系,泛化关系,例,1,：查找（同一任务不同对象）,例,2,：识别（同一任务不同方法）,用例图概念,重要关系,用例之间的关系,包含关系,用例的包含关系是把一件事情划分为多个步骤处理,用例图概念,重要关系,用例之间的关系,包含关系,包含关系把几个用例的公共步骤分离成一个单独的被包含用例,被包含用例称作,提供者用例（基本用例），,包含用例称作,客户用例,，提供者用例提供功能给客户使用。,包含用例不能单独执行，必须与基本用例一起执行,包含用例没有特定的,actor,，包含用例的,actor,实际上是基本用例的,actor,用例图概念,重要关系,用例之间的关系,包含关系,用例图概念,重要关系,用例之间的关系,扩展关系,一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系,扩展关系是,把新的行为插入到已有用例,中的方法。,例：还书，超期,用例图概念,重要关系,用例之间的关系,扩展关系,在,UML,中，扩展关系表示为虚线箭头加,字样，箭头指向被扩展的用例（即基础用例）。,基础用例的扩展增加了原有的语义，此时是基础用例而不是扩展用例被作为例子使用。,用例图概念,重要关系,思考：,扩展,泛化,用例图概念,重要关系,思考：,包含,包含,用例图概念,用例描述,用例描述,用例描述是指对一个用例的功能进行的文字描述,是参与者与系统交互动作序列的说明,.,用例采用自然语言描述参与者与系统的交互行为,要易于理解。其读者是开发人员、用户、项目经理、测试人员等。,用例描述是用例的主要部分,是后续的交互图分析和类图分析必不可少的部分,.,用例图概念,用例描述,用例,use case,用例描述（用例规约）,对于每一个用例，需要有详细的描述信息，以便让别人了解整个系统。用例描述一般包含以下内容：,简要说明,:,对用例作用和目的的简要描述。,事件流,:,事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。,用例场景,:,同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。,特殊需求,:,特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。,前置条件,:,执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。,后置条件,:,用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。,1.,用例名称：新增书籍信息（,UC01,）,2.,简要说明：录入新购书籍信息，并自动存储建档。,3.,事件流：,3.1,基本事件流,3.2,扩展事件流,4.,用例场景：唯一场景,5.,特殊需求：无,6.,前置条件：用户进入图书管理系统。,7.,后置条件：完成新书信息的存储建档。,用例描述,-,个人图书管理系统,用例图概念,用例描述,用例图概念,用例描述,用例描述,描述用例的关键要素,：用例何时开始（前置条件）、何时结束（后置条件）、参与者何时与用例交互、交互了什么信息，以及用例执行的,基本事件流,和,扩展事件流,事件流,事件流就是一个用例在执行时参与者与系统之间的交互过程。,事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。,事件流分为基本事件流和扩展事件流两种。,用例描述模板,用例描述有两种格式：一种是纯文本格式，另一种是表格形式。,描述项,说明,用例名称,表明用户的意图或用例的用途，与用例图相符,标识符,可选,惟一标识符,便于引用该用例,用例描述,概述用例的几句话,参与者,与此用例相关的参与者,优先级,一个有序的排列, 1,代表优先级最高,场景,可选,用例场景或状态,前置条件,一个条件列表,这些条件必须在访问用例前得到满足,后置条件,一个条件列表,这些条件必须在用例完成之后得到满足,主事件流,描述用例中各项工作都顺利进行时用例的工作方式,扩展事件流,描述变异工作方式、出现异常或发生错误的情况下的路径,用例图概念,用例描述,用例描述格式,用例图概念,用例描述,用例描述格式,描述项,说明,被泛化的用例,此用例所泛化的用例列表,被包含的用例,此用例所包含的用例列表,被扩展的用例,此用例所扩展的用例列表,修改历史记录,可选,关于用例的修改时间、修改原因、修改人的详细信息,问题,可选,与此用例的开发有关的问题列表,决策,可选,关键决策的列表,将这些决策信息记录下来以便维护时使用,频率,可选,参与者访问此用例的频率,如,:,每日一次,/,每月一次等,用例图概念,用例描述,用例描述,用例描述容易出现的错误,只描述系统的行为,没有描述参与者的行为,只描述参与者的行为,没有描述系统的行为,在用例描述中就设定了对用户界面的设计的要求,描述过于冗长,Use case: Withdraw cash,Actor: customer,主事件流：,储户插入,ATM,卡,并输入密码,储户按“取款”按钮,并输入取款数目,储户取走现金,/ATM,卡,/,收据,储户离开,Use case: Withdraw cash,Actor: customer,主事件流：,ATM,系统获得,ATM,卡和密码,设置交易类型为“取款”,ATM,系统获得取款金额,输出现金、收据和,ATM,卡,系统复位,只描述了,actor,的行为,只描述了,System,的行为,ATM,系统“取款”用例的两个错误描述：,用例描述,ATM,系统“取款”用例的正确描述：,用例图概念,用例描述,Use case: Withdraw cash,Actor: customer,主事件流：,储户通过读卡机插入,ATM,卡,ATM,系统从卡上读取银行,ID,、账号、加密密码,并通过主银行系统验证银行,ID,和账号,储户输入密码, ATM,系统根据加密密码对输入密码进行验证,储户按 “取款”按钮,并输入取款数目,该数目应该为,100,的倍数,ATM,系统通知主银行系统,传递账号和金额,并接收返回的确认信息和账户余额,ATM,系统输出现金、,ATM,卡和收据,ATM,系统记录交易到日志文件,创建用例图,用例分析的基本流程,基本功能分析,参与者分析,找出系统外部的参与者和外部系统,确定系统边界和范围,确定每一个参与者所期望的系统行为,用例分析,用例初步确定,进一步确定,用例关系分析,初步绘制用例图,用例描述,细化用例图,解决用例间重复与冲突的问题,.,创建用例图,实例分析：语音邮箱系统,基本功能分析,语音邮箱系统中,可以为每个系统用户,(,邮箱主人,),分配一个语音邮箱号码。,进行留言时，拨打语音邮箱系统的主号码， 在听到提示音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的问候语后，进行留言然后挂断电话。,邮箱主人拨打语音邮箱系统的主号码，在听到提示音“请输入邮箱号”后，输入语音邮箱号，听到主人设定的问候语后， 输入密码,+#,进行邮箱管理。此时系统提供三种服务：,1.,接收信息；,2.,更改问候语；,3.,更改密码。其中接收留言包括收听新留言、存储留言、删除留言等。,创建用例图,实例分析：语音邮箱系统,参与者分析,参与者：,留言人、邮箱主人,系统行为分析,留言人留言,邮箱主人管理信息：收听,/,存储,/,删除。,邮箱主人更改问候语。,邮箱主人更改密码。,创建用例图,实例分析：语音邮箱系统,用例分析,用例初步确定,留言人：保留信息,邮箱主人：接收信息、更改问候语、更改密码,用例进一步确定,留言人：拨打邮箱号码,邮箱主人：拨打邮箱号码、登录邮箱,用例关系分析,留言人角度：包含关系,邮箱主人角度：包含关系,创建用例图,实例分析：语音邮箱系统,初步绘制用例图,创建用例图,实例分析：语音邮箱系统,用例描述,拨打邮箱号,呼叫者拨打语音邮件系统的主号码。,语音邮件系统发出提示音：输入邮箱号码并加,#,号。,呼叫者输入接收者的邮箱号。,语音邮件系统发出问候语：已进入,XX,的邮箱，请留言。,保留信息,呼叫者完成邮箱号输入操作,.,呼叫者说出信息,.,呼叫者挂断电话,.,语音邮件系统将记录的信息存放在接收者的邮箱中,.,创建用例图,实例分析：语音邮箱系统,用例描述,登录系统,邮箱用户完成邮箱号输入操作,.,邮箱用户键入密码并后跟,#,键,.(,默认号码与邮箱号相同,),语音邮件系统播放邮箱菜单,:,按,1,键接收信息,.,按,2,键更改密码,.,按,3,键更改问候语,.,创建用例图,实例分析：语音邮箱系统,用例描述,更改问候语,略,更改密码,略,接收语音信息,略,创建用例图,实例分析：语音邮箱系统,细化用例图,解决用例间重复与冲突的问题更改问候语,拨打邮箱号重复，可以合并,创建用例图,课堂练习：图书管理系统,基本功能：,读者：借书、还书，书籍预订；,图书馆管理员：书籍借出、书籍归还、预订信息,系统管理员：增加书目、删除或更新书目、增加书籍、减少书籍、增加读者账户信息、删除或更新读者账户信息、书籍信息查询、读者信息查询等。,请按照用例分析基本流程绘制用例图,要求,使用,rose,或者,PowserDesigner,
展开阅读全文