第3章 需求分析与用例建模教学课件.pptx

《第3章 需求分析与用例建模教学课件.pptx》由会员分享，可在线阅读，更多相关《第3章 需求分析与用例建模教学课件.pptx（138页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第3章需求分析与用例建模在线开放课程SDUFE面向对象的系统分析与设计在线开放课程第3章需求分析与用例建模引引导导案例案例3.1需求分析需求分析3.2用例建模用例建模3.3活活动图动图建模建模3.4需求分析与用例建模需求分析与用例建模实实例例在线开放课程引导案例l自动取款机（自动取款机（ATMATM）的需求）的需求l有的人说，ATM的功能是取款、存款、查询余额，所以针对ATM的需求应该是：取款、存款、查询余额。l有的人说，ATM的功能有很多，如识别卡、密码认证、点钞、验钞、查询余额、跨行取款等，所以针对ATM的需求应该是：识别卡、密码认证、点钞、验钞、查询余额、跨行取款。在线开放课程引导案例l

2、问题：问题：l如果你是ATM购买商，你认为哪种才是你的需求?l如果你是ATM制造者，你认为哪种才是你的需求?l如果你是ATM使用者，你认为哪种才是你的需求?l需求和功能的差别：需求和功能的差别：l需求：对客户来说是有价值的事情。需求：对客户来说是有价值的事情。l功能：系统为了实现客户价值而提供的能力。功能：系统为了实现客户价值而提供的能力。l因此，区别是需求还是功能的方法很简单：因此，区别是需求还是功能的方法很简单：只需要判断是否只需要判断是否对客户有价值。对客户有价值。在线开放课程3.1需求分析lRUPRUP中将需求分析定义为一个核心工作流，其目标中将需求分析定义为一个核心工作流，其目标是描

3、述系统应该做什么。是描述系统应该做什么。l需求分析的任务就是理解系统所解决问题的定义和需求分析的任务就是理解系统所解决问题的定义和范围，使系统开发人员能够清楚地了解系统需求，范围，使系统开发人员能够清楚地了解系统需求，与客户和其他参与者在系统的工作内容方面达成共与客户和其他参与者在系统的工作内容方面达成共识并保持一致，包括：定义系统边界、为计划迭代识并保持一致，包括：定义系统边界、为计划迭代的技术内容提供基础、为估算开发系统所需成本和的技术内容提供基础、为估算开发系统所需成本和时间提供依据以及对需要的功能和约束进行提取、时间提供依据以及对需要的功能和约束进行提取、组织和文档化。组织和文档化。在

4、线开放课程3.1需求分析l需求分析的重要性需求分析的重要性l在系统开发过程中，定义需求是非常具有挑战性的工作，涉及不同背景的项目团队的协作。客户是领域专家，对系统的功能有总体的考虑，但软件技术及开发的经验可能会不足。系统开发团队的技术经验丰富，但对用户个性化的日常业务流程的细节缺乏深入的了解。这将导致需求的表达和定义出现偏差。l需求的定义：（1）用户解决问题或达到目标所需的条件或权能（Capability）；（2）系统或系统部件要满足合同、标准、规范或其他正式文档所需具有的条件或权能；（3）一种能反应上面两条所描述的条件或权能的文档说明。l需求是客户可接受的、系统必须提供的功能和必须满足的特性

5、。在线开放课程3.1需求分析l在统一过程（在统一过程（RUPRUP）中，需求按照）中，需求按照“FURPS+”“FURPS+”模模型可进行以下型可进行以下5 5种分类种分类：l功能性（Functional）：详细描述系统的特性、应具备的功能和安全性；l可用性（Usability）：详细描述系统的人性化因素（准确的错误提示、美观性、易用性）、细致的帮助、操作文档和培训资料；l可靠性（Reliability）：详细规定系统的故障频率、可恢复性、可预测性；l性能（Performance）：详细规定系统在功能性需求上施加的条件，比如：响应时间、吞吐量、准确性、有效性、资源利用率；l可支持性（Suppo

6、rtability）：详细规定系统的适应性、可维护性、国际化、可配置性。在线开放课程3.1需求分析l“FURPS+”“FURPS+”中的中的“+”“+”是指一些辅助性的和次要的因素：是指一些辅助性的和次要的因素：l实现（Implementation）：资源限制、语言和工具、硬件等；l接口（Interface）：强加于外部系统接口之上的约束；l操作（Operation）：对其操作设置的系统管理；l包装（Packaging）例如物理的包装盒；l授权（Legal）：许可证或其他方式。l用户的需求可以划分为功能性（行为的）和非功能性（其它所有的行为）需求。l（1）功能性需求系统要具体完成业务方面的需求

7、。例如：客户登录、管理商品、浏览商品及购买商品等。l（2）非功能性需求是指软件产品为满足用户业务需求而必须具有的特性，包括系统的并发性、可靠性、可维护性、可扩充性等。在线开放课程3.1需求分析l需求分析的需求分析的过程过程l需求分析是发现、精炼、建模和规格说明的过程。包括：明晰系统开发计划中规定的系统边界。创建所需的数据模型、功能模型和控制模型。分析可选择的解决方案，并将它们分配到各个软件成分中去。l需求分析的过程可以分成4个阶段：问题识别问题识别：进行系统开发的可行性分析和并确定实施计划分析与综合：分析与综合：从系统的角度对各种功能及性能的各项要求进行一致性检查。需求描述：需求描述：编制需求

8、分析阶段的文档需求评审：需求评审：对功能的正确性，文档的一致性、完备性、准确性和清晰性，及其他需求给予评价在线开放课程3.2用例建模从从现实世界到世界到业务模型模型在线开放课程3.2用例建模l用例建模是用于描述一个用例建模是用于描述一个系统的功能系统的功能的建模技术，即回答的建模技术，即回答系统应该系统应该“做什么做什么”的问题，是由系统需求分析到最终实的问题，是由系统需求分析到最终实现的第一步。现的第一步。l在需求阶段，用例模型是表达系统外部事物（参与者）与在需求阶段，用例模型是表达系统外部事物（参与者）与系统之间交互的可视化工具。系统之间交互的可视化工具。l一个系统的用例模型由若干用例图组

9、成，用简单的图符准一个系统的用例模型由若干用例图组成，用简单的图符准确地描述了参与者与系统的交互情况以及系统的功能。在确地描述了参与者与系统的交互情况以及系统的功能。在用例模型中，功能以用例来表示，每个用例指明了一个完用例模型中，功能以用例来表示，每个用例指明了一个完整的功能。整的功能。l在需求阶段，用例模型是将系统考虑成黑盒，参与者向系在需求阶段，用例模型是将系统考虑成黑盒，参与者向系统提供输入，系统响应参与者的输入，而不是系统如何做统提供输入，系统响应参与者的输入，而不是系统如何做的内部细节。的内部细节。在线开放课程3.2用例建模在线开放课程3.2用例建模l用例建模的用例建模的过程包括：程

10、包括：找出找出系统边界系统边界；识别与识别与系统进行交互的系统进行交互的参与者参与者；分析参与者使用每一项系统功能时的执行过程，通过分析参与者使用每一项系统功能时的执行过程，通过用例用例来描述每一项功能来描述每一项功能；形成由参与者、用例以及它们之间的形成由参与者、用例以及它们之间的关系关系所构成的所构成的用用例图例图；进行用例描述，形成进行用例描述，形成用例规约用例规约。在线开放课程3.2.1用例图l用例用例图是系是系统需求分析到最需求分析到最终实现的第一步，将的第一步，将系系统的功能划分的功能划分为对参与者（系参与者（系统的用的用户）有用）有用的需求，并以每个系的需求，并以每个系统开开发参

11、与者容易理解的方参与者容易理解的方式来表达系式来表达系统。l用例用例图是从参与者使用系是从参与者使用系统的角度来描述系的角度来描述系统功功能，也就是描述系能，也就是描述系统的参与者、用例以及它的参与者、用例以及它们之之间的关系，但不描述的关系，但不描述这些功能在系些功能在系统内部的内部的实现过程。程。在线开放课程3.2.1用例用例图图在线开放课程l用例用例图包括：包括：系系统边界界参与者、用例、关系（注解与参与者、用例、关系（注解与约束）束）参与者之参与者之间关系：泛化关系：泛化参与者与用例之参与者与用例之间：通信：通信用例之用例之间的关系：泛化、的关系：泛化、扩展与包含展与包含3.2.1用例

12、用例图图在线开放课程3.2.1用例图用例图元素参与者参与者用例用例直接直接关联关联关联关联扩展扩展包含包含泛化泛化建模元素建模元素在线开放课程l系统边界：一个系统所包含的所有系统成分与系系统边界：一个系统所包含的所有系统成分与系统以外各种事物的分界线。统以外各种事物的分界线。边界内：系统本身所包含的全部对象。边界内：系统本身所包含的全部对象。边界外：与系统进行信息交换的各种事物，即人员、设边界外：与系统进行信息交换的各种事物，即人员、设备和外系统等各种参与者备和外系统等各种参与者3.2.2系统边界在线开放课程l系统的边界与开发的目标、任务和规模大小有关。系统的边界与开发的目标、任务和规模大小有

13、关。可以通过辨析问题域中的事物与系统的关系，来确可以通过辨析问题域中的事物与系统的关系，来确定系统的边界。现实世界中事物与系统的关系包括定系统的边界。现实世界中事物与系统的关系包括如下几种情况：如下几种情况：某些事物位于系统边界内，成为系统的元素。某些事物直接与系统进行交互，系统内部没有相应的成分作为它们的抽象表示，这些事物就是系统边界外的参与者。某些事物既在系统边界以外与系统进行直接交互，又作为一个系统对象对其进行抽象性描述。某些事物是当前问题域需要使用的一个已经存在的系统（这样的系统此时不需要再开发），那么这样的系统被看作一个外部系统，作为系统的参与者存在。3.2.2系统边界在线开放课程3

14、.2.3参与者（actor）l参与者的定参与者的定义：在系统之外与系统进行交互的人、其人、其他系统、硬件设备、时间他系统、硬件设备、时间人：当系人：当系统需要与某人交互需要与某人交互时如：如：ATM系系统中的客中的客户硬件硬件设备：当系：当系统需要与硬件需要与硬件设备交互交互时如：门禁系统中的磁卡读写器如：门禁系统中的磁卡读写器其他系其他系统：当系：当系统需要与其他系需要与其他系统交互交互时如：如：ATMATM系统中，银行后台系统就是参与者系统中，银行后台系统就是参与者计时器（器（时间）：当系）：当系统需要周期性的定需要周期性的定时触触发时如：周期性的向系统发起定时事件如：周期性的向系统发起定

15、时事件在线开放课程l参与者的表示形式：3.2.3参与者（actor）在线开放课程l如何如何发现参与者参与者人人员l首先从接受系统服务的人员中发现参与者。（直接使用）l从为系统直接提供服务的各类人员中发现参与者。（直接对话）3.2.3参与者（actor）在线开放课程例例1:1:客户给销售员发来传真订货，客户给销售员发来传真订货，销售员下班前将当日订货销售员下班前将当日订货单汇总输入系统。单汇总输入系统。谁是系统的谁是系统的ActorActor？例例2:2:商品销售系统。顾客通过网络下单之后，系统计算出总计商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的

16、会计系统，金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。该系统是另外购买的。有几个有几个ActorActor？系系统直接使用者直接使用者系系统的服的服务对象象与系与系统交互的信息系交互的信息系统3.2.3参与者（actor）?在线开放课程l设备对内与系统相联，对外不必经过与人员的交互而直接发挥某种作用的设备。监控传感器为“生成警报”用例提供传感器输入，监控操作员查看警报信息3.2.3参与者（actor）在线开放课程l外系外系统与本系统相联，并进行信息交互；可以是其他子系统、上级系统或任何与它进行协作的系统；它的开发不是自己这个分析员小组的当前责任。远程系统启动用例，监

17、控操作员接收监控数据，并从该用例中获得价值3.2.3参与者（actor）在线开放课程l计时器当系统需要定期输出某些信息时，定时器参与者可以周期性的向系统发送定时事件。报告计时器参与者启动“显示周报”用例，该用例周期性准备一份每周报告供给用户查看3.2.3参与者（actor）在线开放课程l如何如何识别参与者参与者谁将使用该系统的主要功能？谁需要系统的支持以完成日常工作任务?谁负责维护、管理系统，保持系统正常工作状态?谁改变了系统的数据信息?谁从系统获取数据信息?该系统需要与哪些外部系统交互?系统需要处理哪些硬件设备?谁(或者哪些外部系统)对该系统产生的结果感兴趣?在预设的时间点，有自动发生的事件

18、吗？3.2.3参与者（actor）在线开放课程l在在识别系系统参与者的参与者的过程中，要注意以下几点：程中，要注意以下几点：参与者参与者对于系于系统而言而言总是外部的。是外部的。参与者直接与系参与者直接与系统进行交互，行交互，这将有助于确定系将有助于确定系统边界。界。参与者表示的是与系参与者表示的是与系统进行交互行交互时扮演的角色，不是特定的扮演的角色，不是特定的人或者特定的事物。人或者特定的事物。一个人或事物在与系一个人或事物在与系统发生交互生交互时，可以扮演多个角色。，可以扮演多个角色。每一个参与者需要有一个能更好表达其角色的名字，如：系每一个参与者需要有一个能更好表达其角色的名字，如：系

19、统管理管理员、会、会员、游客等，不推荐使用、游客等，不推荐使用诸如如“新参与者新参与者”这样的名字。的名字。每个参与者必每个参与者必须有有简短的描述，从短的描述，从业务角度描述参与者是什角度描述参与者是什么。像么。像类一一样，表示参与者属性和它可接受的事件。，表示参与者属性和它可接受的事件。识别参与者参与者时要注意，参与者一定是直接并且主要注意，参与者一定是直接并且主动地向系地向系统发出出动作并作并获得反得反馈的，否的，否则就不是参与者。就不是参与者。3.2.3参与者（actor）在线开放课程l参与者与参与者与业务工人工人l在实际的工作中，建模者常常会面临一个问题，谁是参与者?例如这样一个场景

20、：小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折。在这个场景中，谁是参与者?l注意两个问题：谁对系统有着明确的目标和要求并且主动发出动作?系统是为谁服务的?l问题：参与者与业务工人（businesswork）3.2.3参与者（actor）在线开放课程l如何区分参与者与业务工人（businesswork）他是主动向系统发出动作的吗?他有完整的业务目标吗?系统是为他服务的吗?l这三个问题的答案如果是否定的，那一定是业务工人。以人工座席这个例子来说，人工座席只有在购票人打电话的情况下才会去购票，因此他是被动的；定票的最终目的是拿到机票，但人工座席只负责定，最终票

21、并不到他的手里，因此他没有完整的业务目标；系统是为购票者服务的。非常明显，人工座席只可能是一个业务工人。3.2.3参与者（actor）在线开放课程l参与者之间的关系参与者之间的关系由于参与者实质上也是类，用例图中的参与者之间有时会出现泛化的关系,这种泛化关系和类图中类之间的泛化关系是相似的。泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。参与者之间的泛化(Generalization)关系表示一个一般性的参与者(称为父参与者)与另一个更为特殊的参与者(称为子参与者)之间的联系。子参与者继承了父参与者的行为和含义，还可以增加自己特有的行为和含义，子参与者可以出现在父参

22、与者能出现的任何位置上。在UML规范中，泛化关系用带空心三角形箭头的实线表示，箭头指向父参与者。3.2.3参与者（actor）在线开放课程l参与者之间的泛化关系3.2.3参与者（actor）在线开放课程l参与者之间的泛化关系3.2.3参与者（actor）在线开放课程l参与者和用例之间的关系参与者和用例之间的关系参与者和用例之间存在着一定的关系，这种关系属于关联关系(Association)，又称为通信关联(CommunicationAssociation)。这种关系表明了哪个参与者与用例通信。在UML规范中，用例图中的参与者和用例之间的关联关系用带箭头或不带箭头的实线表示，箭头表示在这关系中哪

23、一方是对话的主动发起者，箭头所指方是对话的被动接受者。在上节图中，“普通用户”参与者主动调用“浏览商品”用例，浏览网站上陈列的商品。所以，箭头指向“浏览商品”用例。如果不想强调对话中的主动者与被动者，或者参与者和用例互为主动者与被动者，则可以使用不带箭头的实线来表示它们之间的关联关系。3.2.3参与者（actor）在线开放课程3.2.4用例（usecase）l用例的定用例的定义：用例是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合。l用例的表示形式：用例的表示形式：在线开放课程l如何如何识别用例？用例？参与者要向系统请求什么功能?每个参与者的特定任务是什么?参与者需要读

24、取、创建、撤销、修改或存储系统的某些信息吗?是否任何一个参与者都要向系统通知有关突发性的、外部的改变?或者必须通知参与者关于系统中发生的事件？这些事件代表了哪些功能?系统需要哪些输入输出？是否所有的功能需求都被用例使用了?3.2.4用例（usecase）在线开放课程l识别用例注意的用例注意的问题：每个用例至少应该涉及一个参与者。如果存在不与参与者进行交互的用例，则应该检查是否遗漏了该用例的参与者。如果确实没有与参与者进行交互，则可考虑将其并入其他用例中。用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定。用例是系统级的、抽象的描述、不是细化的（考虑“做什么（what）”,而不是“

25、怎么做（how）”）。对复杂的系统划分为若干个子系统处理。3.2.4用例（usecase）在线开放课程l判断用例的判断用例的标准准用例可以解释为某个参与者（用例可以解释为某个参与者（actoractor）通过系统要做的）通过系统要做的事情，这件事通常具有以下特征：事情，这件事通常具有以下特征：这件事（用例）是相对独立的。这件事（用例）是相对独立的。l意味着它不需要与其他用例交互而独自完成参与者意味着它不需要与其他用例交互而独自完成参与者的目的。也就是说用例从的目的。也就是说用例从“功能功能”上说是完备的。上说是完备的。用例本质体现了系统参与者的愿望，不能完整达到用例本质体现了系统参与者的愿望，

26、不能完整达到参与者愿望的不能称为用例。参与者愿望的不能称为用例。3.2.4用例（usecase）在线开放课程l判断用例的判断用例的标准准这件这件事（用例）的事（用例）的执行结果对参与者来说是可观测的和执行结果对参与者来说是可观测的和有意义的。有意义的。例如，有一个后台进程监控参与者在系统里的操作，并例如，有一个后台进程监控参与者在系统里的操作，并在参与者删除数据之前执行备份操作虽然它是系统的一在参与者删除数据之前执行备份操作虽然它是系统的一个必需的组成部分，但它在需求阶段却不应该作为用例个必需的组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台程序，对参与者来说是不可观出现。因为这

27、是一个后台程序，对参与者来说是不可观测的，它应该作为系统需求在补充规约中定义而不是一测的，它应该作为系统需求在补充规约中定义而不是一个用户需求。比如说，登录系统是一个有效的用例，但个用户需求。比如说，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但单纯地输入密的，这样他可以获得身份认证和授权，但单纯地输入密码却是没有意义的，输入完了呢码却是没有意义的，输入完了呢?有什么结果吗有什么结果吗?3.2.4用例（usecase）在线开放课程l判断用例的判断用例的标准准这件这件事（用例）必须事

28、（用例）必须由一个参与者发起；不存在没有参由一个参与者发起；不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。另一个用例。3.2.4用例（usecase）在线开放课程l判断用例的判断用例的标准准这件这件事（用例）必然事（用例）必然以动宾短语形式出现的。以动宾短语形式出现的。3.2.4用例（usecase）在线开放课程l怎怎样确定用例的粒度？确定用例的粒度？用例的粒度可大可小，一般一个系统控制在20个左右，但没有严格规定。用例是系统级的、抽象的描述、不是细化的（考虑“做什么（what）”,而不是“怎么做（how）”）。对复杂的

29、系统划分为若干个子系统处理。3.2.4用例（usecase）在线开放课程l用例的命名：用例的命名：从参与者的角度出发进行命名（如使用“登录”而不是“身份验证”）；使用动宾结构或主谓结构命名；尽量使用行业术语。3.2.4用例（usecase）在线开放课程3.2.5用例图中的关系泛化关系扩展关系（构造型）包含关系（构造型）在线开放课程1.泛化关系l泛化关系：用泛化关系：用连接两个参与者（或者用例）接两个参与者（或者用例）表示为一个参与者（用例）可以被特别列举为一个或多个子参与者（子用例）泛化是从下到上的抽象泛化是从下到上的抽象过程，从特殊到一般的程，从特殊到一般的过程。程。在线开放课程l包含关系：

30、包含关系：在进行需求分析时，通常会发现有些功能在不同环境下都可以使用，则把某些功能独立出来，成为单独的用例。虽然每个用例都是独立的，但一个用例可以用其他更简单的用例来描述。l包含关系描述的是一个用例需要某种功能，而该功能被另外一个用例定义，那么在用例的执行过程中，就可以调用已经定义好的用例。则称一个用例（基础用例）包含另一个用例（包含用例）的功能。2.包含关系在线开放课程2.包含关系l“包含包含”关系关系：使用虚的依赖线加上构造型，形如的形式连接两个用例。表示前一个用例的执行需要借助调用后一个子用例的功能。后一个用例称为包含用例包含用例，前一个用例称为基本用例基本用例。在线开放课程l包含关系：

31、包含关系：一个用例可以包含其他用例具有的行为，可以在以下三种情况下引入包含关系：提取公共事件流提取公共事件流用例分解用例分解简化用例简化用例2.包含关系在线开放课程l提取公共事件流提取公共事件流：如果两个以上的用例有大量相同如果两个以上的用例有大量相同的行为，则可以将这段行为抽象到另一个用例中，的行为，则可以将这段行为抽象到另一个用例中，其他用例可以和这个用例建立包含关系。其他用例可以和这个用例建立包含关系。2.包含关系在线开放课程l用例分解用例分解：一个用例的功能太多，可以用包含关系一个用例的功能太多，可以用包含关系建模几个小用例。建模几个小用例。例如：在开发系统中，总是存在着维护某某信息的

32、功能，例如：在开发系统中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来用例和删除用例，则划分太细。这时包含关系可以用来理清关系。理清关系。2.包含关系在线开放课程l简化用例简化用例：可利用包含关系用来组织一个冗长的用可利用包含关系用来组织一个冗长的用例（基用例提供参与者和系统之间高层次的交互。例（基用例提供参与者和系统之间高层次的交互。包含用例提供参与者和系统之间低层次的

33、交互）。包含用例提供参与者和系统之间低层次的交互）。2.包含关系在线开放课程3.扩展关系l扩展关系：展关系：表示后一个用例（扩展用例）是对前一个用例（基用例）的可选增量扩展事件，即它是前一个用例的可选附加行为。（扩展用例向基用例添加了些额外的行为）l使用虚的依赖线加上构造型，形如的形式连接两个用例。注意在线开放课程l扩展用例被定义为基础用例的增量扩展。l注意：注意：基础用例本身是完整的，可以单独存在，在每次执行基础用例时，扩展用例不是每次都被执行。扩展用例的执行必须依赖于基础用例。扩展点是基础用例中的一个或多个位置，在该位置会衡量某个条件以决定是否启用扩展用例。扩展点定义了启动扩展用例的条件，

34、一旦该条件满足，则扩展用例将被使用。3.扩展关系在线开放课程l基础用例提供扩展点以添加新的行为。3.扩展关系在线开放课程l在超市系统中，基用例“顾客结账”中声明一个“付款”的扩展点。基用例处理顾客结账，三个扩展用例的类型为现金结账、信用卡结账、借记卡结账。为每个扩展用例提供一个选择条件。扩展关系使用扩展点名称和选择条件标注。三个扩展条件是互斥的。3.扩展关系在线开放课程关系总结l参与者之间：泛化关系l参与者与用例之间：通信关系l用例与用例之间：泛化、包含和扩展l包含关系和扩展关系的异同：相同点：它们都是基本用例的行为的一部分；不同点：在基本用例的每一次执行时，包含用例都一定会执行，而扩展用例只

35、是偶尔被执行。在线开放课程l用例建模的步用例建模的步骤：找出系找出系统外部的参与者和外部系外部的参与者和外部系统,确定系确定系统的的边界和界和范范围。确定每一个参与者所期望的系确定每一个参与者所期望的系统行行为，即参与者，即参与者对系系统的基本的基本业务需求。需求。把把这些系些系统行行为作作为基本用例。基本用例。区分用例的区分用例的优先次序。先次序。细化每个用例。使用泛化、包含、化每个用例。使用泛化、包含、扩展等关系展等关系处理系理系统行行为的公共或的公共或变更部分。更部分。编写每个用例的用例描述。写每个用例的用例描述。绘制用例制用例图。编写写项目目词汇表。表。用例建模步用例建模步骤骤（细细化

36、）化）在线开放课程3.2.6用例描述（用例规约）l在用例在用例图中，一个用例是用一个命名的中，一个用例是用一个命名的椭圆表示的，但表示的，但如果没有如果没有对这个用例的具体个用例的具体说明，那么明，那么还是不清楚是不清楚该用用例到底会完成什么功能。例到底会完成什么功能。l没有描述的用例就像是一本没有描述的用例就像是一本书的目的目录，人，人们只知道只知道该目目录标题，但并不知道，但并不知道该目目录的具体内容是什么。所以的具体内容是什么。所以说，仅用用图形符号表示的用例本身并不能提供形符号表示的用例本身并不能提供该用例所具用例所具备的全部信息，必的全部信息，必须通通过文本的方式描述文本的方式描述该

37、用例的完整功用例的完整功能。事能。事实上上,用例的描述才是用例的主要部分，是后用例的描述才是用例的主要部分，是后续的的交互交互图分析和分析和类图分析必不可少的部分。分析必不可少的部分。l用例描述用例描述(UseCaseSpecification)实际上是一个关于上是一个关于参与者与系参与者与系统如何交互的如何交互的规范范说明，明，该规范范说明要清晰明要清晰明了明了,没有歧没有歧义性。性。在线开放课程3.2.6用例描述l由于用例描述了参与者和由于用例描述了参与者和软件系件系统进行交互行交互时，系，系统所所执行的一系列的行的一系列的动作序列。因此，作序列。因此，这些些动作序列不但作序列不但应包含正

38、常使用的各种包含正常使用的各种动作序列作序列（称称为主事件流或基本操主事件流或基本操作流程），而且作流程），而且还应包含包含对非正常使用非正常使用时软件系件系统的的动作序列作序列（称称为子事件流或可子事件流或可选操作流程）。所以，主事操作流程）。所以，主事件流（基本操作流程）描述和子事件流（可件流（基本操作流程）描述和子事件流（可选操作流程）操作流程）描述是用例描述的主要内容。描述是用例描述的主要内容。l需要注意的是，在表述用例描述需要注意的是，在表述用例描述时，仍然注重描述系，仍然注重描述系统从外部看到的行从外部看到的行为。用例描述的内容。用例描述的内容还应包括用例激活包括用例激活前的前置条

39、件，前的前置条件，说明如何启明如何启动用例，以及用例，以及执行行结束后的束后的后置后置结果，果，说明在什么情况下用例才被明在什么情况下用例才被认为是完成的。是完成的。此外此外,在用例描述中除了表明主要步在用例描述中除了表明主要步骤与与顺序外，序外，还应表表明可明可选操作流程和特殊需求。操作流程和特殊需求。在线开放课程用例描述的内容l用例名称用例名称：每个用例都：每个用例都给予一个名字。予一个名字。l概述：概述：用例的用例的简短描述，一般是一两句短描述，一般是一两句话。l参与者：参与者：该部分部分给用例中的参与者命名。用例中的参与者命名。总有一个主要参与有一个主要参与者启者启动用例。用例。l优先

40、先级:说明明对该用例用例进行分析行分析设计实现的的紧迫程度。迫程度。l前置条件：前置条件：这些条件必些条件必须在在访问该用例之前得到用例之前得到满足足,包括哪包括哪个参与者或用例在怎个参与者或用例在怎样的情况下启的情况下启动执行行该用例。用例。l后置条件：后置条件：这些条件必些条件必须在在该用例完成以后得到用例完成以后得到满足足,包括明包括明确在什么情况下用例才能被看作完成确在什么情况下用例才能被看作完成,完成完成时要把什么要把什么结果果值传递给参与者或系参与者或系统.l基本操作流程基本操作流程(主事件流主事件流)描述：描述：用例的主体是用例的主体是对该用例主序列用例主序列的叙述性描述，的叙述

41、性描述，这是参与者和系是参与者和系统之之间最最经常的交互序列。常的交互序列。该描述的形式是参与者的描述的形式是参与者的输入，接着是系入，接着是系统的响的响应。在线开放课程l可可选操作流程操作流程(可替可替换事件流事件流)描述：描述：主序列的可替主序列的可替换分支分支的叙述性描述。主序列可能有多个可替的叙述性描述。主序列可能有多个可替换分支。例如：如分支。例如：如果客果客户的的账号没有足号没有足够的的资金，金，则显示抱歉并退出卡片。示抱歉并退出卡片。在在给出可替出可替换描述的同描述的同时，用例中可替，用例中可替换序列从主序列分序列从主序列分支出来的支出来的这个步个步骤也被也被标识出来。出来。l特

42、殊需求：特殊需求：描述描述该用例的非功能性需求和用例的非功能性需求和设计约束。束。l被泛化的用例：被泛化的用例：描述描述该用例所泛化的用例列表用例所泛化的用例列表,即父用例列即父用例列表表,而此用例作而此用例作为子用例。子用例。l被包含的用例：被包含的用例：描述描述该用例所包含的用例列表用例所包含的用例列表,即包含用例即包含用例列表列表,而此用例作而此用例作为基本用例。基本用例。l被被扩展的用例：展的用例：描述描述该用例所用例所扩展的用例列表展的用例列表,即即扩展用例展用例列表列表,而此用例作而此用例作为基本用例。基本用例。l未解决的未解决的问题：在在开开发期期间，有关用例的，有关用例的问题被

43、被记录下来，下来，用于和用用于和用户进行行讨论用例描述的内容在线开放课程案例1：ATM机系统的问题域描述l通通过使用使用ATM机，客机，客户能能够从支票从支票账户或者存或者存储账户提取提取提取提取现现金金金金、查询查询账户账户余余余余额额、在、在账户间转账转账。客。客户将一个将一个ATM卡插入卡插入读卡器会启卡器会启动那个那个一个交易。一个交易。ATM卡背面的磁条里卡背面的磁条里编码保存了保存了该卡的卡号、生效期和失卡的卡号、生效期和失效期。如果一效期。如果一张ATM卡能卡能够被系被系统识别，那么系，那么系统会会验证这张卡的卡的过期情况。客期情况。客户输输入入入入PINPIN并并并并进进行行行

44、行验证验证，并可确，并可确认该卡是否被挂失；客卡是否被挂失；客户可可以以尝试输入三次入三次PIN码，若三次，若三次输入入错误则没收卡。没收卡。l若若输入的入的PIN通通过了了验证，则客客户可以可以进行取款、行取款、查询获转账交易。在交易。在取款交易被取款交易被许可之前，系可之前，系统需确需确认该取款取款账户是否是否拥有足有足够的金的金额、取款取款额度未超度未超过单日取款上限以及本地提款机中日取款上限以及本地提款机中拥有足有足够的的现金。如金。如果果该交易交易获得了需求，得了需求，则ATM机将提取指定的取款金机将提取指定的取款金额、打印包含交、打印包含交易信息的凭条并易信息的凭条并弹出出ATM卡

45、。在卡。在转账交易被交易被许可前，系可前，系统需确需确认客客户拥有至少两个有至少两个账户以及待以及待转出的出的账户中中拥有足有足够的金的金额。对于被允于被允许的的查询和和转账请求，求，ATM机会打印凭条并机会打印凭条并弹出出ATM卡。客卡。客户可以在任可以在任何何时候取消交易，如果交易被取消，那么候取消交易，如果交易被取消，那么ATM卡也会被卡也会被弹出。服出。服务器器中保留了所有的客中保留了所有的客户记录、账户记录以及借以及借记卡卡记录。在线开放课程ATM机系统用例图在线开放课程包含用例包含用例“验证密密码”用例名称用例名称验证PIN码概述概述系统验证客户参与者参与者客户基本操作流程基本操作

46、流程1.客户向读卡器插入ATM卡。2.如果系统识别了该卡，则读取卡号。3.系统提示客户输入PIN码。4.客户输入PIN码。5.系统检查该卡的有效期，是否已经报告丢失或遭窃。6.如果卡是有效的，则系统检查用户输入的PIN码是否和系统存储的PIN码匹配。7.如果PIN码数字匹配，则系统检查该ATM卡可访问哪些账户。8.系统显示客户账号，并提示客户交易类型：取款、查询或转账。可可选操作流程操作流程2a：如果系统未能识别该卡，则弹出该卡5a：如果系统确认该卡失效，则没收该卡5b:如果系统确认该卡已被挂失（遗失或者被盗），那么系统没收该卡7a：如果客户输入的PIN码不正确，那么系统提示用户重新输入PIN

47、码。7b:如果客户输错三次PIN码，则系统没收该卡。步骤48：如果客户选择“取消”选项，则系统取消交易并弹出卡片后置条件后置条件客户的密码已被验证ATM机系统用例描述在线开放课程用例名称用例名称取款概述概述客户从有效的银行账户提取特定数量的钱款参与者参与者ATM客户前置条件前置条件ATM机验证密码通过基本操作流程基本操作流程1.客户选择取款。2.系统提示客户输入取款金额。3.客户输入取款金额。4.系统检查客户在该账户中的余额是否充足，以及用户输入的取款金额是否超过取款上限。5.系统验证通过，则授权允许本次取款请求。6.系统分发相应数额的现金。7.客户核对现金金额，并确认交易。8.系统打印凭条，

48、显示交易号、交易类型、取款金额和账户余额信息。9.客户取款成功，选择退卡。10.系统弹出ATM卡。可可选操作流程操作流程4a：如果系统确认客户账户上没有足够的金额，则系统显示“账户余额不足”的提示信息并弹出卡片。4b：如果系统确定取款金额超过了每日取款上限，那么系统显示“取款超过限额”的提示信息并弹出卡片。6a：如果ATM机现金不够，则系统显示“ATM机内余额不足”的提示信息，并弹出卡片。步骤18：如果客户选择“取消”选项，则系统取消交易并弹出卡片。后置条件：后置条件：客户账户的金额已被扣除在线开放课程“顾客结账”用例图在线开放课程基用例基用例“顾客客结账”用例名称：用例名称：顾客结账概述：概

49、述：系统为顾客结账前置条件：前置条件：结账台空闲，显示“欢迎”消息。主序列：主序列：1.顾客扫描所选的商品；2.系统显示商品名称、价格和累计总价；3.对每一项购买的商品，顾客重复步骤1和2；4.顾客选择付款方式；5.系统提示现金付款、信用卡付款或借记卡付款；6.付款；7.系统屏幕显示“谢谢”。被被扩展用例：展用例：现金结账、信用卡支付、借记卡支付 在线开放课程在该用例的描述中，第6步付款是一个占位符，标识了有个合适的扩展用例在此执行。对于扩展用例“现金结账”，扩展条件是称作现金付款的选择条件。当条件现金付款为真时，该扩展用例会被执行。扩展用例展用例“现金金结账”用例名称：用例名称：现金结账 概

50、述：概述：顾客为购买的商品使用现金结账参与者：参与者：顾客 基用例：基用例：扩展顾客结账前置条件：前置条件：顾客已经扫描了商品，但尚未付款主序列：主序列：1.顾客选择现金付款；2.系统提示顾客放入纸币或硬币等现金；3.客户放入现金;4.系统计算找零;5.系统显示应付款总额、现金付款额和找零;6.系统在收据上打印应付款总额、现金付款额和找零。在线开放课程对扩展用例“信用卡结账”，选择条件为信用卡付款，当此条件为真（用户选择信用卡结账），该扩展用例会被执行。扩展用例展用例“信用卡信用卡结账”用例名称用例名称：信用卡结账 概述：概述：顾客为购买的商品用信用卡结账参与者：参与者：顾客 基用例：基用例：