软件工程模型与方法 第9章 面向对象分析课件

第九章面向对象分析修佳鹏xiujiapeng@软件工程模型与方法

Models&MethodsofSoftwareEngineering©2008

BUPTTSEG第九章面向对象分析软件工程模型与方法

Models&M本章内容9.1面向对象分析综述9.2用例建模9.3创建领域模型9.4绘制系统顺序图9.5创建系统操作契约©2008

BUPTTSEG北京邮电大学通信软件工程中心本章内容9.1面向对象分析综述©2008BUPTTS9.1面向对象分析综述面向对象分析（Object-OrientedAnalysis，简称OOA）就是运用面向对象的方法进行系统分析，强调运用面向对象方法，对问题域和系统职责进行分析和理解，找出描述问题域及系统职责所需的对象，定义对象的属性、服务以及它们之间的关系，目标是建立一个符合问题域、满足用户需求的OOA模型。问题域（problemdomain）：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围系统职责（systemresponsibilities），所开发的系统应该具备的职能©2008

BUPTTSEG北京邮电大学通信软件工程中心9.1面向对象分析综述面向对象分析（Object-OrieOOA与OOD的职责划分OOA针对现实世界中的问题域与系统职责，用面向对象的方法建立起针对问题域和系统职责的模型，作为分析的结果。OOA模型不考虑与系统的具体实现相关的因素（譬如，采用什么程序设计语言和数据库），从而使OOA模型独立于具体的实现环境。OOD则是针对系统的具体实现，运用OO方法进行系统设计。其中包括两方面的工作：一是根据实现条件对OOA模型做某些必要的调整和修改，使其成为OOD模型的一部分；二是针对具体实现条件，建立人机界面、数据存储和控制驱动等模型。这些部分与OOA采用相同的概念和表示法。©2008

BUPTTSEG北京邮电大学通信软件工程中心OOA与OOD的职责划分OOA针对现实世界中的问题域与系统职软件分析所面临的问题1．对问题域和系统职责的理解

2．交流问题3．需求的不断变化4．软件复用的要求©2008

BUPTTSEG北京邮电大学通信软件工程中心软件分析所面临的问题1．对问题域和系统职责的理解©200面向对象分析步骤（1）利用用例以及用例图来捕获和描述用户的需求，从而建立系统的功能需求模型。为创建需求模型，首先要从业务需求描述出发，识别参与者和使用场景；对场景进行汇总、分类和抽象，形成用例；确定参与者和用例、用例和用例之间的关系，形成用例模型。（2）从业务需求描述和用例描述中提取“关键概念”，形成领域模型。©2008

BUPTTSEG北京邮电大学通信软件工程中心面向对象分析步骤（1）利用用例以及用例图来捕获和描述用户的需面向对象分析步骤（3）从用例出发，将系统看作一个黑盒子，识别出参与者和系统交互的系统事件，在系统顺序图中进行描述，并进一步识别出系统操作。（4）从系统顺序图和领域模型出发，建立系统操作契约，描述响应系统事件的系统操作执行后对系统状态的影响，从而回答系统“做什么”的问题。此处的系统状态变化指的是领域模型中概念的创建和删除，概念属性的修改以及概念之间关联的建立和删除。©2008

BUPTTSEG北京邮电大学通信软件工程中心面向对象分析步骤（3）从用例出发，将系统看作一个黑盒子，识别©2008

BUPTTSEG北京邮电大学通信软件工程中心©2008BUPTTSEG北在线考试系统功能描述本系统主要是为程序设计类课程考试而设计，但是也应该能适应到其他的课程。目的在于：1.增加考试灵活性，减轻任课教师的出题、判卷和统计工作；2.避免纸面考程序设计题的一些缺陷；3.增加一些统计分析功能，便于老师及时跟踪学生对知识点的掌握情况。©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统功能描述本系统主要是为程序设计类课程考试而设计，系统用户教师学生助教©2008

BUPTTSEG北京邮电大学通信软件工程中心系统用户教师©2008BUPTTSEG子系统描述1.题库管理子系统对考题进行管理。题目类型有选择题、填空题、解答题和程序设计题，功能要求：能增、删、改、查询题目。能支持使用Excel批量导入试题到数据库的功能。2.考试子系统根据一定的试题生成规则现场生成一套试题供学生进行解答，并记录答案。考试采用逐题方式进行，做完一题再出现下一题。学生可以用上翻、下翻键来选择返回上一题还是进行到下一题。考试采用人工计时方式。若到考试结束时间，则系统强行要求学生结束答题；若学生提前做完，则可以按结束考试键终止答题。当学生选择结束考试时，给出选择题的成绩，并将学生所做的试题及答案记录到数据库中。©2008

BUPTTSEG北京邮电大学通信软件工程中心子系统描述1.题库管理子系统©2008BUPTTSE子系统描述3.阅卷子系统为了方便老师批量批改解答题和程序设计题，系统能灵活支持将某道题的学生解答汇总成一个文档供老师拿回去批阅，并将阅后成绩导入数据库中。4.给分子系统在每小题的成绩都已经给出的情况下，统计出每一个学生的最终机考成绩并记载到数据库中。5.统计子系统统计子系统主要是提供考试结果分析信息，以方便老师了解考试情况，对教学结果做出较好的评估。©2008

BUPTTSEG北京邮电大学通信软件工程中心子系统描述3.阅卷子系统©2008BUPTTSEG用例建模目标画出系统用例图识别系统边界识别参与者识别用例确定用例之间关系给出用例的文本描述用例描述模板©2008

BUPTTSEG北京邮电大学通信软件工程中心用例建模目标画出系统用例图©2008BUPTTSEG9.2用例建模9.2.1确定系统边界9.2.2识别参与者9.2.3识别用例9.2.4其他需求分析工作©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2用例建模9.2.1确定系统边界©2008BUP9.2.1确定系统边界系统边界是一个系统所包含的所有系统成分与系统以外各事物的分界线。系统边界以外是与系统进行交互的人员、设备、外部系统或组织。系统是由一条边界包围起来的未知空间，系统只通过边界上的有限个接口与外部交互。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.1确定系统边界系统边界是一个系统所包含的所有系统成9.2.2识别参与者参与者（actor）是具有行为能力的事物，可以是一个人（由所扮演的角色来识别）、计算机系统或硬件设备。它们位于系统边界之外，通过和系统进行有意义的交互来实现它们的目标。识别参与者的任务就是找到参与者并明确其在系统中要实现的目标。参与者是一个类。参与者可以发出请求，要求系统提供服务，系统以某种方式进行响应，或者把响应的结果给其他的参与者；系统也可以向参与者发出请求，参与者对此做出响应。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.2识别参与者参与者（actor）是具有行为能力的事参与者的分类主要参与者：指的是在使用系统服务的过程中满足自己目标的那些参与者，如使用在线考试系统的任课教师和学生。识别出这类参与者，可以帮助找到用户目标，从而确定系统的功能需求。次要参与者：指的是为系统提供服务的那些参与者，如一个对信用卡支付进行授权的外部系统。识别出这类参与者，可以帮助确定外部接口和协议。后台参与者：指的是对用例的行为感兴趣的那些参与者，如政府的税务机关。识别出这类参与者，可以保证找到所有方面的兴趣并让用例满足之。©2008

BUPTTSEG北京邮电大学通信软件工程中心参与者的分类主要参与者：指的是在使用系统服务的过程中满足自己谁能充当参与者人员：可以从直接使用系统的人员中发现参与者。其从系统获取信息，或者向系统提供信息。外部系统：所有与系统交互的外部系统。设备：所有与系统交互的设备。其与系统相连，向系统提供外界信息，或者从系统获取信息，在系统的控制下运行。例如传感器、受控马达、条形码扫描设备等。©2008

BUPTTSEG北京邮电大学通信软件工程中心谁能充当参与者人员：可以从直接使用系统的人员中发现参与者。其如何找到参与者通过回答以下问题找到参与者：（1）谁使用系统的主要功能？（2）谁需要系统的支持以完成其日常工作任务？（3）谁负责维护、管理并保证系统的正常运行？（4）系统需要和哪些外部系统交互？（5）系统需要处理哪些设备？（6）对系统产生的结果感兴趣的人或事物是哪些？©2008

BUPTTSEG北京邮电大学通信软件工程中心如何找到参与者通过回答以下问题找到参与者：©2008BU如何识别参与者的目标可以通过回答以下问题识别参与者的目标：（1）某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作(可能有些工作需要系统帮助完成）？（2）参与者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息吗？（3）系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？（4）由于系统新功能的识别（如那些典型的还没有实现自动化的人工系统），参与者的日常工作被简化或效率提高了吗？若是，则该用例对于该参与者有意义、值得实现。©2008

BUPTTSEG北京邮电大学通信软件工程中心如何识别参与者的目标可以通过回答以下问题识别参与者的目标：©参与者之间的继承关系参与者是一个类，因此在参与者之间可以引入类之间的继承关系，通过定义某个抽象参与者来简化参与者的定义。如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承，这种关系称为参与者之间的继承关系。©2008

BUPTTSEG北京邮电大学通信软件工程中心参与者之间的继承关系参与者是一个类，因此在参与者之间可以引入在线考试系统的参与者四类主要参与者：任课教师、助教、学生和系统维护人员。各个参与者的系统目标：任课教师：能维护题库；能设计一次考试的出题规则，设定考生范围和考试时间及时长；能顺利开展考试；能方便有效地开展阅卷工作；能得到有价值的统计信息。助教：能方便有效地开展阅卷工作；学生：能顺利进行考试，能查询自己的考试成绩；系统维护人员：能对系统的用户、权限、系统参数等进行方便地维护。©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的参与者四类主要参与者：任课教师、助教、学生和系在线考试系统的参与者任课教师的部分目标和助教的目标相同，于是可以创建一个新的抽象参与者――阅卷者，它的目标是使用系统方便有效地开展阅卷工作；教师和助教再继承阅卷者阅卷者教师助教学生系统维护人员©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的参与者任课教师的部分目标和助教的目标相同，于是9.2.3识别用例用例的定义：一个用例（usecase）描述系统的一项功能，功能被描述为一组动作序列（场景）的集合。每一个动作序列表示参与者与系统的一次交互，将为参与者产生一个可观察的结果值。每一个用例使用动词短语定义，该短语描述了系统必须完成的目标。对定义的理解：（1）一个用例描述系统的一项功能，是参与者使用系统来达成目标时一组相关的成功场景（scenario）和失败场景的集合。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.3识别用例用例的定义：©2008BUPTTS对用例的理解（2）用例通常是由某个参与者来驱动执行，只有当外部的参与者与系统交互时，该功能才会发生作用。（3）用例中，只描述参与者可以看到的系统行为特征。（4）用例描述的是一个参与者所使用的一项系统级功能，该项功能应该相对完整。（5）可观察的结果值是指系统对参与者的动作要做出响应，在经过若干次交互之后，系统把最终有意义的结果值反馈给参与者。©2008

BUPTTSEG北京邮电大学通信软件工程中心对用例的理解（2）用例通常是由某个参与者来驱动执行，只有当外识别用例从参与者角度出发，识别每类参与者在系统中要实现的目标，从中抽取用例。用例可以分为三种不同的级别：企业级别的目标：如盈利、扩大目标市场等；用户级别的目标：如取款、在线考试等；子功能级别的目标：如验证用户身份、记录系统日志等。识别用例重点要识别的是用户级别用例。©2008

BUPTTSEG北京邮电大学通信软件工程中心识别用例从参与者角度出发，识别每类参与者在系统中要实现的目标基本业务过程基本业务过程（EBP，ElementaryBusinessProcess）是指由一个人在某个时间某个地点执行的一项任务，这项任务是对某一业务事件的反应，而且能够增加可以度量的业务价值，并且能够保持数据状态的一致。进行用例分析时，应该专注于EBP级别的用例，但是当一个子功能在多个用户目标级别用例中重复出现，或这个子功能是多个用户目标级别用例的前置条件，如“验证用户身份”、“记录日志”等，则可以定义一个用例来表示该子功能。©2008

BUPTTSEG北京邮电大学通信软件工程中心基本业务过程基本业务过程（EBP，ElementaryB用例描述用例描述的目标是将用例的功能和应用场景描述清楚，包括用例在何时开始，何时结束参与者何时与系统交互交互什么内容所有可能的交互场景对用例的描述，可以用自然语言，也可以采用用户自定义的语言。为了更清楚地说明问题，也可以采用面向对象的类图、交互图、状态图或活动图来做进一步的描述。

©2008

BUPTTSEG北京邮电大学通信软件工程中心用例描述用例描述的目标是将用例的功能和应用场景描述清楚，包括用例描述模板用例编号:每一个用例一个唯一的编号，方便在文档中索引。

用例名称:(状语＋）动词＋（定语＋）宾语，体现参与者的目标。

范围：应用的软件系统范围

级别：企业目标级别/用户目标级别/子系统目标级别

主要参与者:调用系统服务来完成目标的主要参与者

项目相关人员及其兴趣:

用户应包含满足所有相关人员兴趣的内容

前置条件:规定了在用例中的一个场景开始之前必须为“真”的条件。

后置条件：规定了用例成功结束后必须为“真”的条件。

主要成功场景:（基本路径）描述了能够满足项目相关人员兴趣的一个典型的成功路径。不包括条件和分支

1．

……

n．

扩展（或替代流程）:（备选路径）说明了基本路径以外的所有其他场景或分支

*a.描述任何一个步骤都有可能发生的条件，前边加*5a.对基本路径中某个步骤的扩展描述，前边加基本路径编号

特殊需求：与用例相关的非功能性需求技术与数据的变化列表：输入输出方式上的变化以及数据格式的变化。发生频率：用例执行的频率。待解决的问题：不清楚的、尚待解决的问题可集中在此进行罗列©2008

BUPTTSEG北京邮电大学通信软件工程中心用例描述模板用例编号:每一个用例一个唯一的编号，方便在文档中用例之间的关系包含关系用例A在其内部说明的某一位置上显式地使用用例B行为的结果，成为用例A包含用例B。包含关系图示表示如下左图。避免用例中相同功能的重复描述；避免过长的用例。扩展关系在不能改变已有用例的情况下，扩展用例的功能。扩展用例中必须包含触发和扩展点说明。扩展管理的图示表示如下右图。基用例被包含的用例《include》基用例扩展用例《extend》©2008

BUPTTSEG北京邮电大学通信软件工程中心用例之间的关系包含关系《include》《extend》©用例的包含关系举例假设在一个旅游电子商务网站系统中，有如下用例：购买机票预定酒店在这两个用例中，都有一个环节是“填写联系资料”，则可以将“填写联系资料”抽象为一个独立的用例，在上述用例中包含该用例，局部用例图如下图所示：购买机票填写联系资料预定酒店《include》《include》©2008

BUPTTSEG北京邮电大学通信软件工程中心用例的包含关系举例假设在一个旅游电子商务网站系统中，有如下用用例1：购买机票主要成功场景：1.顾客输入航班查询条件；2.系统显示查询结果；……11.顾客填写联系方式，包含填写联系资料用例。12.顾客选择信用卡支付，填写信用卡信息。用例2：预订酒店主要成功场景：1.顾客输入酒店查询条件；2.系统显示查询结果；3．顾客填写入住时间；……8.顾客填写联系方式，包含填写联系资料用例。用例10：填写联系资料级别：子功能主要成功场景：1.顾客在联系方式界面内输入办公电话、手机、Email、邮寄地址和邮箱，点击提交。2.系统验证上述信息格式有效。扩展（或替代流程）：2a.系统发现有必填信息没有填写1.系统给出提示信息；2.顾客填写信息，回到主要成功场景的步骤2。2b.系统验证信息格式不正确1.系统给出提示信息；2.顾客重新填写信息，回到主要成功场景的步骤2。包含关系用例描述©2008

BUPTTSEG北京邮电大学通信软件工程中心用例1：购买机票用例2：预订酒店用例10：填写联系资料包含关用例的扩展关系假设在“购买机票”用例中，基用例不能修改，此时需要在信用卡支付环节，增加“里程换机票”的功能，此时，可以将该功能抽象为扩展用例，以扩展基本用例的功能。扩展后的局部用例图如下图所示：购买机票里程换机票《extend》©2008

BUPTTSEG北京邮电大学通信软件工程中心用例的扩展关系假设在“购买机票”用例中，基用例不能修改，此时扩展用例的描述用例1：购买机票（基用例）主要成功场景：1.顾客输入航班查询条件；2.系统显示查询结果；……11.顾客填写联系方式，包含填写联系方式用例。12.顾客选择信用卡支付，填写信用卡信息。用例12：里程换机票(扩展用例)触发：顾客选择用里程积分支付航班费用扩展点：购买机票用例中的步骤12。所处层次：子功能。主要成功场景：1.系统验证顾客是否有足够的积分。2.系统从顾客当前积分中扣除相应积分，将剩余积分告诉顾客。©2008

BUPTTSEG北京邮电大学通信软件工程中心扩展用例的描述用例1：购买机票（基用例）用例12：里程换机票在线考试系统的用例图设置考试时间、考试班级、考试规则；生成学生密码；增、删、改考试设置对成绩特别差的学生，老师可以查阅其完整的试卷，分析其薄弱点所在©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的用例图设置考试时间、考试班级、对成绩特别差的学在线考试系统的用例描述用例编号用例名称使用人用例描述用例1批阅答案（按学生）阅卷者在线逐个学生地批阅答案。用例2批阅答案（按考题）阅卷者批量导出某题的所有解答，另存为文件供教师离线批阅

用例3批量导入成绩阅卷者按照指定的格式，将批量批阅的题目的得分一次性导入

用例4维护成绩阅卷者阅卷者能对成绩进行增、删、改、查用例5配置考试教师设置考试的时间和时长、考试使用的试题生成规则、参加考试的班级等信息用例6维护试题生成规则教师包括对试题生成规则的增、删、改、查用例7维护题库教师包括对各类试题的增、删、改、查

用例8查询学生卷面教师生成某一个学生的卷面（word格式），并提供下载或打印功能

用例9批量计算学生总成绩教师批量计算出各学生的总成绩

用例10批量计算学生总成绩教师生成指定班级按学号升序排列的学生成绩清单

用例11生成统计报表教师对一些有价值的结果进行统计分析用例12查看统计报表教师查看统计报表©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的用例描述用例编号用例名称使用人用例描述用例1批在线考试系统的用例描述用例编号用例名称使用人用例描述用例13维护系统参数

系统维护人员维护系统配置数据信息用例14维护学生基本信息系统维护人员对学生基本信息进行维护，包括增加、修改、删除等。用例15维护教师基本信息系统维护人员对教师基本信息进行维护，包括增加、修改、删除等。用例16维护课程基本信息系统维护人员对课程基本信息进行维护，包括增加、修改、删除等。用例17管理用户系统维护人员对系统登录用户信息进行维护用例18管理用户权限系统维护人员对系统用户的权限进行管理用例19查询成绩学生查询某次考试的成绩用例20考试学生参加某次考试©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的用例描述用例编号用例名称使用人用例描述用例13“考试”用例文本描述用例编号:UC001用例名称:考试范围：在线考试系统级别：用户目标级别主要参与者:学生项目相关人员及其兴趣:

学生：顺利进行考试，能准确快速地提交答案，考试不间断，时钟计时准确，系统响应时间在1秒之内。老师：能按照考卷生成规则对每个考生自动生成一套考卷，能准确记录学生答案，能准确计时。前置条件:考试已经设置（考卷生成规则，考试时间，考试对象），监考老师已经启动该考试生效，监考老师已经核实完学生身份，学生已从监考老师处获得考试密码并登陆系统，进入系统主窗口。后置条件：如果考试成功，则系统记录学生的考题及答案，并当场给出选择题分数；如果考试失败，所有信息均不进行记录。©2008

BUPTTSEG北京邮电大学通信软件工程中心“考试”用例文本描述用例编号:UC001用例名称:“考试”用例文本描述主要成功场景:1．学生在系统主窗口中选择参加考试。2．系统列出该学生该时段能参加的所有考试课程名称。3．学生选择其中的一门课程，要求考试。4．系统弹出登陆框，要求学生输入考试密码。5学生输入从监考老师处获取的考试密码，登陆。6．系统显示欢迎界面，展示考试课程名称和考试时长，询问学生是否开始考试。7．学生选择开始考试。8．系统按照预先设计好的考卷生成规则自动生成一套考卷。9．系统显示考题。10．学生答题，并提交该题答案。11．系统记录答案，并使上一题或下一题按钮生效。12．学生选择上一题或者下一题。系统重复步骤9～12，直到学生选择结束考试或者考试时间到。13.系统显示学生的选择题得分。14．系统询问学生是否退出考试。15．学生选择退出。16．系统回到系统主窗口。©2008

BUPTTSEG北京邮电大学通信软件工程中心“考试”用例文本描述主要成功场景:1．学生在系统主窗口中选择“考试”用例文本描述扩展（或替代流程）:*aA任何时刻，如果学生使用的电脑出现问题：为了支持恢复操作和正确地记录考生信息，要保证所有考试过程中的敏感状态和事件都能够从上述场景中任何一步中完全恢复。1.学生重启系统，登陆，请求恢复上次状态。2.系统重建之前的状态（包括考题和已经提交的答案）。2a.系统恢复过程中检测到异常：1．系统向学生指示错误，学生记录错误，向监考老师报告。2．学生在监考老师安排下更换一台电脑重新登录继续考试。5a.系统验证输入的用户名或者密码无效：1．系统显示提示信息。2．用户重新输入用户名和密码。3．系统验证密码有效，回到主要成功场景的步骤6。3a.系统验证输入的用户名或者密码无效,且验证次数小于3次：回到5a的步骤1。3b.系统验证输入的用户名或者密码无效,且验证次数已经3次：系统进行提示，强迫学生回到系统主窗口。7a.学生选择稍后开始考试：屏幕上提示准备时间为3分钟。2．3分钟后自动进入考试。回到主要成功场景的步骤8。10a.学生答题却未提交答案：1．系统不记录答案，并使上一题或下一题按钮生效。回到主要成功场景的步骤12。9-12a.学生选择提前结束考试：1．系统询问学生是否确实提前结束考试。2．学生确认结束。回到主要成功场景的步骤13。2a.学生选择继续考试。回到前一状态。15a.学生不选择退出：1．系统进入30秒倒计时。2．30秒后自动退出原考试界面，回到主要成功场景的步骤16。©2008

BUPTTSEG北京邮电大学通信软件工程中心“考试”用例文本描述扩展（或替代流程）:*aA任何时刻，如“考试”用例文本描述特殊需求：系统对每个操作的反应应在1秒钟内。学生使用分配的密码成功登陆后，只能进入考试界面，不可启动其他应用程序（如QQ、MSN等）和破坏系统。技术与数据的变化列表：目前学生参与考试过程中只可以使用键盘和鼠标作为交互设备。将来可以考虑增加触摸屏。发生频率：期中、期末使用。待解决的问题：1．如果学生考试中途觉得题目太难继续不下去，是否给他重新出一套题在剩下的时间继续考试？2．考虑到扩展性和通用性，系统是否要能同时支持两种出题模式，即1）试题在考试之前先生成、全班通用，2）试题在考试时才生成，每人的题目均不一样？3．目前该系统主要支持期中、期末以班为单位的集中式程序设计测试。但将来是否还要能支持平时一些达标类的小测试？对于此类测试，是否可以多给几次机会，让学生在规定时间内再次考试？达标总成绩如何计算？如何确保是本人参加考试?©2008

BUPTTSEG北京邮电大学通信软件工程中心“考试”用例文本描述特殊需求：系统对每个操作的反应应在1秒钟UML活动图描述©2008

BUPTTSEG北京邮电大学通信软件工程中心UML活动图描述©2008BUPTTSEG9.2.4其他需求分析工作在统一过程UP中，除了用例模型，需求分析工件(artifact)中还有：补充规范（supplementaryspecification）：记录系统的非功能性需求，同时也记录用例模型中没有表达或者不方便表达的功能特性列表。术语表（glossary）：记录关键的领域术语。项目构想文档（vision）描述系统高层的目标、功能和约束，以便让项目相关人员快速地对系统有一个全局的了解，这些目标、功能和约束在用例模型和补充规范中会进行细化。业务规则描述（businessrules）：也称为领域规则，通常描述业务需求和处理策略，应用系统必须要遵守这些规则和策略。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.4其他需求分析工作在统一过程UP中，除了用例模型，9.3创建领域模型9.3.1识别概念类9.3.2添加关联9.3.3添加属性©2008

BUPTTSEG北京邮电大学通信软件工程中心9.3创建领域模型9.3.1识别概念类©2008BU领域模型简介领域模型就是用来描述业务领域重要概念及其相互关系的模型，一般用UML的类图来表达，其中概念用类来表示，概念之间的关系用关联、继承、聚合来表示。理解领域模型对理解系统需求至关重要，领域模型的创建步骤如下：第1步，找出当前需求中的候选概念类；第2步，在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。第3步，在概念类之间添加必要的关联来记录那些需要保存记忆的关系。第4步，在概念类中添加用来实现需求的必要属性。©2008

BUPTTSEG北京邮电大学通信软件工程中心领域模型简介领域模型就是用来描述业务领域重要概念及其相互关系9.3.1识别概念类创建领域模型需要经过多次迭代，增量地建立一个领域模型。两种识别概念类的技巧：使用概念类分类列表：通过建立一个候选概念类的列表来开始创建领域模型。识别名词短语：识别有关问题域文本描述中的名词和名词短语，然后将它们作为候选的概念类或者属性。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.3.1识别概念类创建领域模型需要经过多次迭代，增量地建使用概念类分类列表概念类分类示例物理或者具体对象商品事物的设计、描述和规范商品规格说明，考题规格说明位置商店交易销售，考卷交易项目销售项，考题人的角色收银员，考生其他事物的容器商店，考卷容器包含的元素商品，考题在该系统之外的系统信用卡支付授权系统抽象名词的概念组织销售部门事件销售，考卷过程（通常不表示成一个概念，但也可以表示成概念）销售一件商品规则和政策考卷生成规则分类产品目录有关工作、契约、财务和法律事物的记录收据、维护日志财务设施及服务©2008

BUPTTSEG北京邮电大学通信软件工程中心使用概念类分类列表概念类分类示例物理或者具体对象商品事物的设识别名词短语1．学生在系统主窗口中选择参加考试。2．系统列出该学生该时段能参加的所有考试课程名称。3．学生选择其中的一门课程，要求考试。4．系统弹出登陆框，要求学生输入考试密码。5学生输入从监考老师处获取的考试密码，登陆。6．系统显示欢迎界面，展示考试课程名称和考试时长，询问学生是否开始考试。7．学生选择开始考试。8．系统按照预先设计好的考卷生成规则自动生成一套考卷。9．系统显示考题。10．学生答题，并提交该题答案。11．系统记录答案，并使上一题或下一题按钮生效。12．学生选择上一题或者下一题。系统重复步骤9～12，直到学生选择结束考试或者考试时间到。13.系统显示学生的选择题得分。14．系统询问学生是否退出考试。15．学生选择退出。16．系统回到系统主窗口。©2008

BUPTTSEG北京邮电大学通信软件工程中心识别名词短语1．学生在系统主窗口中选择参加考试。2．系统列出在线考试系统中的概念类©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统中的概念类©2008BUPTTSEG9.3.2添加关联领域模型中的关联可分为两种：“需要知道”型关联：需要将概念之间的关系信息保持一段时间的关联。领域模型中需要着重考虑。“只需理解”型关联：有助于增强对领域中关键概念的理解的关联。寻找关联时要遵循下述指导原则：1．将注意力集中在需要知道型关联。2．识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。3．太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。4．避免显示冗余或导出关联。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.3.2添加关联领域模型中的关联可分为两种：©2008通用关联表分类示例A在物理上是B的一部分树木－森林A在逻辑上是B的一部分销售项－销售考题－考卷A在物理上包含在B中或者依赖于B商品－货架A在逻辑上包含在B中考卷生成规则项－考卷生成规则A是对B的描述考题规格说明－考题A是交易或者报表B中的一项销售项－销售考题－考卷A为B所知/为B所记录/录入B中/为B所捕获A是B的一个成员收银员－商店A是B的一个组织子单元销售部－商店A使用或管理B收银员－POS机A与B通信顾客－收银员A与一个交易B有关学生－考试顾客－销售A是一个与另一个交易B有关的事务支付－销售A与B相邻商品－商品A为B所拥有POS机－商店A是一个与B有关的事件考试－学生销售－顾客©2008

BUPTTSEG北京邮电大学通信软件工程中心通用关联表分类示例A在物理上是B的一部分树木－森林A在逻辑上在线考试系统通用关联表分类示例A在物理上是B的一部分不适用A在逻辑上是B的一部分考题－考卷A在物理上包含在B中或者依赖于B不适用A在逻辑上包含在B中考卷生成规则项－考卷生成规则A是对B的描述考题规格说明－考题

课程规格说明－课程A是交易或者报表B中的一项考题－考卷A为B所知/为B所记录/录入B中/为B所捕获不适用A是B的一个成员不适用A是B的一个组织子单元不适用A使用或管理B不适用A与B通信不适用A与一个交易B有关学生－考试A是一个与另一个交易B有关的事务不适用A与B相邻考题－考题A为B所拥有不适用A是一个与B有关的事件考试－学生©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统通用关联表分类示例A在物理上是B的一部分不适用A考试系统中“需要知道型”关联关联含义学生“参加”考试为了知道学生是否需要参加该项考试老师“监考”考试为了知道由哪（几）位老师监考考卷“记录着”考题为了知道一份考卷由哪些考题组成考卷生成规则“对应于”课程为了知道是哪门课程的考卷生成规则考卷生成规则“应用于”考试为了知道某次考试使用哪套考卷生成规则考卷生成规则“记录着”考卷生成规则项为了知道一套考卷生成规则由哪些细项组成考题规格说明“详细描述”考题为了知道一道考题的详细描述©2008

BUPTTSEG北京邮电大学通信软件工程中心考试系统中“需要知道型”关联关联含义学生“参加”考试为了知道在线考试系统部分领域模型©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统部分领域模型©2008BUPTTSEG9.3.3添加属性属性是对象的数据特性，领域模型中的属性往往是需要记忆的信息。识别属性时应注意以下几点：尽量用简单数据类型定义属性；识别属性时首先识别最重要的属性，忽略那些派生属性；对每一个属性，要赋予一个有意义的名称。除了概念类的属性，也要寻找关联上的属性。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.3.3添加属性属性是对象的数据特性，领域模型中的属性往在线考试系统部分属性概念属性课程开课时间……课程规格说明课程编号，课程名称，学分，课程简要介绍……学生学号，班级，姓名，联系Email……选课选课年份，课程总评成绩……老师工作证号，姓名，职称，所在院系名称，联系电话，联系Email……授课授课时间，授课教室……监考应到人数，实到人数，考场情况简述……考试考试时间，考试时长，考试地点……考卷总分……考卷生成规则测试对象，测试目的，内容范围综述，考卷难度，规则创建人，规则创建时间，规则生效标志……考卷生成规则项题目类型、题目难度、内容分类、题目数量……考题解答，得分……考题规格说明题目类型、题目难度、内容分类、分数、创建时间、创建人、生效标志……©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统部分属性概念属性课程开课时间……课程规格说明课程9.4绘制系统顺序图系统行为描述一个系统做什么，描述系统行为的有三种工件用例：描述系统行为的第一个抽象层次系统顺序图：第二个抽象层次系统操作契约：在系统顺序图和领域概念模型基础上得到的第三个抽象层次从第一层次到第三层次，抽象程度在逐步降低。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.4绘制系统顺序图系统行为描述一个系统做什么，描述系统行系统顺序图一个系统顺序图用来表示在用例的一个特定场景中，外部参与者产生的事件、事件的顺序以及系统之间的事件。在交互期间，参与者会向系统发送事件，系统通过响应这些事件来满足参与者的目标。为了识别系统事件，需要从用例的主要成功场景以及频繁或复杂的替代场景中寻找系统事件，建立系统顺序图。系统顺序图应看作是用例模型的一部分，是用例中交互的可视化。需要注意的是，不要一次性创建所有用例所有场景的系统顺序图，应该只为当前迭代所选择的场景创建系统顺序图。©2008

BUPTTSEG北京邮电大学通信软件工程中心系统顺序图一个系统顺序图用来表示在用例的一个特定场景中，外部考试用例场景中的事件从“考试”用例的成功场景中找出的系统事件共有7个：getAvailableTestPapers(学生)selectTestPaper(学生选择其中一门课程进行考试）logonTestPaper(学生登陆一门考试)startTest（学生开始考试）submitAnswer（学生提交答案）getNextQuestion（学生获取上一题或者下一题）endTest（学生结束考试）。©2008

BUPTTSEG北京邮电大学通信软件工程中心考试用例场景中的事件从“考试”用例的成功场景中找出的系统事件考试场景UML顺序图©2008

BUPTTSEG北京邮电大学通信软件工程中心考试场景UML顺序图©2008BUPTTSEG9.5创建系统操作契约系统操作：处理系统事件的操作；一般情况下与系统事件具有相同的名字和参数；操作契约是为系统操作而定义的，描述系统操作执行的结果，模板如下表所示：操作：操作以及参数的名称交叉引用：（可选择）可能发生此操作的用例前置条件：在操作执行前，领域模型中系统或对象状态的值得注意的假设，他们在此操作的逻辑内不会得到测试，而被假设为真，同时，他们并非无关紧要，而应让读者了解此假设的存在。后置条件：操作完成后领域模型中对象的状态。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.5创建系统操作契约系统操作：处理系统事件的操作；一般情创建操作契约的指导原则契约不是必须的。如果用例可以提供大多数或者所有设计需要的细节，那么契约没有什么价值。创建操作契约的指导原则如下：1.首先从系统顺序图中识别系统事件，然后针对每一个系统事件设计对应的系统操作。2.对于那些复杂的、结果微妙的以及在用例中不清晰的系统操作，构造一个契约，作为用例的补充。3.要描述后置条件。后置条件对于领域概念状态变化的描述关注下面三个方面：实例创建和删除。属性修改。关联形成和断开。特别是在创建了新的实例后，往往需要和多个对象之间建立关联。©2008

BUPTTSEG北京邮电大学通信软件工程中心创建操作契约的指导原则契约不是必须的。如果用例可以提供大多数创建操作契约的指导原则4．后置条件的陈述应该采用过去时态的声明语气和被动句型，以强调系统状态所发生的变化，而不是强调这种变化是如何设计实现的。5．在需求工作时，如果要为一个系统操作建立契约，那么为系统操作产生一个完整、详细的后置条件集有时是不可能甚至是不需要的。©2008

BUPTTSEG北京邮电大学通信软件工程中心创建操作契约的指导原则4．后置条件的陈述应该采用过去时态的声考试系统中的系统操作考试系统中的7个系统操作：getAvailableTestPapers(stuId:string)selectTestPaper(courseName:string)logonTestPaper(pwd:string),startTest()submitAnswer(questionId:string,answer:string)getNextQuestion()endTest()©2008

BUPTTSEG北京邮电大学通信软件工程中心考试系统中的系统操作考试系统中的7个系统操作：©2008logon操作：logon(role:string,Id:string,pwd:string)登陆系统交叉引用：用例：登陆前置条件：无后置条件：1．一个考生实例被创建（实例的创建）。©2008

BUPTTSEG北京邮电大学通信软件工程中心logon操作：logon(role:string,Id:startTest操作：startTest()开始考试交叉引用：用例：考试前置条件：一个考卷实例、一个考生实例、若干个考题规格说明实例已经创建后置条件：1．一个考试实例被创建；2．考试实例和考卷实例形成关联；3．一个考卷生成规则实例被创建；4．考卷生成规则实例和考试实例形成关联；5．若干个考卷生成规则项实例被创建；6．考卷生成规则项实例和考卷生成规则实例建立关联；7．若干个考题子类的实例被创建（实例的创建，根据考卷生成规则）。8．考题子类的实例和考卷实例形成关联（关联的形成）。9．一个考题子类的实例和一个考题规格说明的实例形成关联（关联的形成，用于从考题规格说明里得到题目描述信息）。©2008

BUPTTSEG北京邮电大学通信软件工程中心startTest操作：startTest()开始考试交endTest操作：endTest()结束考试交叉引用：用例：考试前置条件：一个考试在进行中后置条件：考卷实例的选择题总分属性被修改（属性的修改）。一个考试实例和一个考卷实例间的关联被断开；一个考卷生成规则实例和一个考试实例间的关联被断开；考卷生成规则项实例和考卷生成规则实例间的关联被断开；考题子类的实例和考卷实例间的关联被断开；一个考题子类的实例和一个考题规格说明的实例被断开；一个考试实例被删除；若干个考卷实例被删除；一个考卷生成规则实例被删除；若干个考卷生成规则项实例被删除；若干个考题子类的实例被删除；若干个考题规格说明的实例被删除；©2008

BUPTTSEG北京邮电大学通信软件工程中心endTest操作：endTest()结束考试交第九章面向对象分析修佳鹏xiujiapeng@软件工程模型与方法

Models&MethodsofSoftwareEngineering©2008

BUPTTSEG第九章面向对象分析软件工程模型与方法

Models&M本章内容9.1面向对象分析综述9.2用例建模9.3创建领域模型9.4绘制系统顺序图9.5创建系统操作契约©2008

BUPTTSEG北京邮电大学通信软件工程中心本章内容9.1面向对象分析综述©2008BUPTTS9.1面向对象分析综述面向对象分析（Object-OrientedAnalysis，简称OOA）就是运用面向对象的方法进行系统分析，强调运用面向对象方法，对问题域和系统职责进行分析和理解，找出描述问题域及系统职责所需的对象，定义对象的属性、服务以及它们之间的关系，目标是建立一个符合问题域、满足用户需求的OOA模型。问题域（problemdomain）：被开发系统的应用领域，即在现实世界中由这个系统进行处理的业务范围系统职责（systemresponsibilities），所开发的系统应该具备的职能©2008

BUPTTSEG北京邮电大学通信软件工程中心9.1面向对象分析综述面向对象分析（Object-OrieOOA与OOD的职责划分OOA针对现实世界中的问题域与系统职责，用面向对象的方法建立起针对问题域和系统职责的模型，作为分析的结果。OOA模型不考虑与系统的具体实现相关的因素（譬如，采用什么程序设计语言和数据库），从而使OOA模型独立于具体的实现环境。OOD则是针对系统的具体实现，运用OO方法进行系统设计。其中包括两方面的工作：一是根据实现条件对OOA模型做某些必要的调整和修改，使其成为OOD模型的一部分；二是针对具体实现条件，建立人机界面、数据存储和控制驱动等模型。这些部分与OOA采用相同的概念和表示法。©2008

BUPTTSEG北京邮电大学通信软件工程中心OOA与OOD的职责划分OOA针对现实世界中的问题域与系统职软件分析所面临的问题1．对问题域和系统职责的理解

2．交流问题3．需求的不断变化4．软件复用的要求©2008

BUPTTSEG北京邮电大学通信软件工程中心软件分析所面临的问题1．对问题域和系统职责的理解©200面向对象分析步骤（1）利用用例以及用例图来捕获和描述用户的需求，从而建立系统的功能需求模型。为创建需求模型，首先要从业务需求描述出发，识别参与者和使用场景；对场景进行汇总、分类和抽象，形成用例；确定参与者和用例、用例和用例之间的关系，形成用例模型。（2）从业务需求描述和用例描述中提取“关键概念”，形成领域模型。©2008

BUPTTSEG北京邮电大学通信软件工程中心面向对象分析步骤（1）利用用例以及用例图来捕获和描述用户的需面向对象分析步骤（3）从用例出发，将系统看作一个黑盒子，识别出参与者和系统交互的系统事件，在系统顺序图中进行描述，并进一步识别出系统操作。（4）从系统顺序图和领域模型出发，建立系统操作契约，描述响应系统事件的系统操作执行后对系统状态的影响，从而回答系统“做什么”的问题。此处的系统状态变化指的是领域模型中概念的创建和删除，概念属性的修改以及概念之间关联的建立和删除。©2008

BUPTTSEG北京邮电大学通信软件工程中心面向对象分析步骤（3）从用例出发，将系统看作一个黑盒子，识别©2008

BUPTTSEG北京邮电大学通信软件工程中心©2008BUPTTSEG北在线考试系统功能描述本系统主要是为程序设计类课程考试而设计，但是也应该能适应到其他的课程。目的在于：1.增加考试灵活性，减轻任课教师的出题、判卷和统计工作；2.避免纸面考程序设计题的一些缺陷；3.增加一些统计分析功能，便于老师及时跟踪学生对知识点的掌握情况。©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统功能描述本系统主要是为程序设计类课程考试而设计，系统用户教师学生助教©2008

BUPTTSEG北京邮电大学通信软件工程中心系统用户教师©2008BUPTTSEG子系统描述1.题库管理子系统对考题进行管理。题目类型有选择题、填空题、解答题和程序设计题，功能要求：能增、删、改、查询题目。能支持使用Excel批量导入试题到数据库的功能。2.考试子系统根据一定的试题生成规则现场生成一套试题供学生进行解答，并记录答案。考试采用逐题方式进行，做完一题再出现下一题。学生可以用上翻、下翻键来选择返回上一题还是进行到下一题。考试采用人工计时方式。若到考试结束时间，则系统强行要求学生结束答题；若学生提前做完，则可以按结束考试键终止答题。当学生选择结束考试时，给出选择题的成绩，并将学生所做的试题及答案记录到数据库中。©2008

BUPTTSEG北京邮电大学通信软件工程中心子系统描述1.题库管理子系统©2008BUPTTSE子系统描述3.阅卷子系统为了方便老师批量批改解答题和程序设计题，系统能灵活支持将某道题的学生解答汇总成一个文档供老师拿回去批阅，并将阅后成绩导入数据库中。4.给分子系统在每小题的成绩都已经给出的情况下，统计出每一个学生的最终机考成绩并记载到数据库中。5.统计子系统统计子系统主要是提供考试结果分析信息，以方便老师了解考试情况，对教学结果做出较好的评估。©2008

BUPTTSEG北京邮电大学通信软件工程中心子系统描述3.阅卷子系统©2008BUPTTSEG用例建模目标画出系统用例图识别系统边界识别参与者识别用例确定用例之间关系给出用例的文本描述用例描述模板©2008

BUPTTSEG北京邮电大学通信软件工程中心用例建模目标画出系统用例图©2008BUPTTSEG9.2用例建模9.2.1确定系统边界9.2.2识别参与者9.2.3识别用例9.2.4其他需求分析工作©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2用例建模9.2.1确定系统边界©2008BUP9.2.1确定系统边界系统边界是一个系统所包含的所有系统成分与系统以外各事物的分界线。系统边界以外是与系统进行交互的人员、设备、外部系统或组织。系统是由一条边界包围起来的未知空间，系统只通过边界上的有限个接口与外部交互。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.1确定系统边界系统边界是一个系统所包含的所有系统成9.2.2识别参与者参与者（actor）是具有行为能力的事物，可以是一个人（由所扮演的角色来识别）、计算机系统或硬件设备。它们位于系统边界之外，通过和系统进行有意义的交互来实现它们的目标。识别参与者的任务就是找到参与者并明确其在系统中要实现的目标。参与者是一个类。参与者可以发出请求，要求系统提供服务，系统以某种方式进行响应，或者把响应的结果给其他的参与者；系统也可以向参与者发出请求，参与者对此做出响应。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.2识别参与者参与者（actor）是具有行为能力的事参与者的分类主要参与者：指的是在使用系统服务的过程中满足自己目标的那些参与者，如使用在线考试系统的任课教师和学生。识别出这类参与者，可以帮助找到用户目标，从而确定系统的功能需求。次要参与者：指的是为系统提供服务的那些参与者，如一个对信用卡支付进行授权的外部系统。识别出这类参与者，可以帮助确定外部接口和协议。后台参与者：指的是对用例的行为感兴趣的那些参与者，如政府的税务机关。识别出这类参与者，可以保证找到所有方面的兴趣并让用例满足之。©2008

BUPTTSEG北京邮电大学通信软件工程中心参与者的分类主要参与者：指的是在使用系统服务的过程中满足自己谁能充当参与者人员：可以从直接使用系统的人员中发现参与者。其从系统获取信息，或者向系统提供信息。外部系统：所有与系统交互的外部系统。设备：所有与系统交互的设备。其与系统相连，向系统提供外界信息，或者从系统获取信息，在系统的控制下运行。例如传感器、受控马达、条形码扫描设备等。©2008

BUPTTSEG北京邮电大学通信软件工程中心谁能充当参与者人员：可以从直接使用系统的人员中发现参与者。其如何找到参与者通过回答以下问题找到参与者：（1）谁使用系统的主要功能？（2）谁需要系统的支持以完成其日常工作任务？（3）谁负责维护、管理并保证系统的正常运行？（4）系统需要和哪些外部系统交互？（5）系统需要处理哪些设备？（6）对系统产生的结果感兴趣的人或事物是哪些？©2008

BUPTTSEG北京邮电大学通信软件工程中心如何找到参与者通过回答以下问题找到参与者：©2008BU如何识别参与者的目标可以通过回答以下问题识别参与者的目标：（1）某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作(可能有些工作需要系统帮助完成）？（2）参与者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息吗？（3）系统中的事件一定要告知参与者吗？参与者需要告诉系统一些什么吗？那些系统内部的事件从功能的角度代表什么？（4）由于系统新功能的识别（如那些典型的还没有实现自动化的人工系统），参与者的日常工作被简化或效率提高了吗？若是，则该用例对于该参与者有意义、值得实现。©2008

BUPTTSEG北京邮电大学通信软件工程中心如何识别参与者的目标可以通过回答以下问题识别参与者的目标：©参与者之间的继承关系参与者是一个类，因此在参与者之间可以引入类之间的继承关系，通过定义某个抽象参与者来简化参与者的定义。如果一组参与者具有共同的性质，可以把这些性质抽取出来放在另一个参与者中，这组参与者再从中继承，这种关系称为参与者之间的继承关系。©2008

BUPTTSEG北京邮电大学通信软件工程中心参与者之间的继承关系参与者是一个类，因此在参与者之间可以引入在线考试系统的参与者四类主要参与者：任课教师、助教、学生和系统维护人员。各个参与者的系统目标：任课教师：能维护题库；能设计一次考试的出题规则，设定考生范围和考试时间及时长；能顺利开展考试；能方便有效地开展阅卷工作；能得到有价值的统计信息。助教：能方便有效地开展阅卷工作；学生：能顺利进行考试，能查询自己的考试成绩；系统维护人员：能对系统的用户、权限、系统参数等进行方便地维护。©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的参与者四类主要参与者：任课教师、助教、学生和系在线考试系统的参与者任课教师的部分目标和助教的目标相同，于是可以创建一个新的抽象参与者――阅卷者，它的目标是使用系统方便有效地开展阅卷工作；教师和助教再继承阅卷者阅卷者教师助教学生系统维护人员©2008

BUPTTSEG北京邮电大学通信软件工程中心在线考试系统的参与者任课教师的部分目标和助教的目标相同，于是9.2.3识别用例用例的定义：一个用例（usecase）描述系统的一项功能，功能被描述为一组动作序列（场景）的集合。每一个动作序列表示参与者与系统的一次交互，将为参与者产生一个可观察的结果值。每一个用例使用动词短语定义，该短语描述了系统必须完成的目标。对定义的理解：（1）一个用例描述系统的一项功能，是参与者使用系统来达成目标时一组相关的成功场景（scenario）和失败场景的集合。©2008

BUPTTSEG北京邮电大学通信软件工程中心9.2.3识别用例用例的定义：©2008BUPTTS对用例的理解（2）用例通常是由某个参与者来驱动执行，只有当外部的参与者与系统交互时，该功能才会发生作用。（3）用例中，只描述参与者可以看到的系统行为特征。（4）用例描述的是一个参与者所使用的一项系统级功能，该项功能应该相对完整。（5）可观察的结果值是指系统对参与者的动作要做出响应，在经过若干次交互之后，系统把最终有意义的结果值反馈给参与者。©2008

BUPTTSEG北京邮电大学通信软件工程中心对用例的理解（2）用例通常是由某个参与者来驱动执行，只有当外识别用例从参与者角度出发，识别每类参与者在系统中要实现的目标，从中抽取用例。用例可以分为三种不同的级别：企业级别的目标：如盈利、扩大目标市场等；用户级别的目标：如取款、在线考试等；子功能级别的目标：如验证用户身份、记录系统日志等。识别用例重点要识别的是用户级别用例。©2008

BUPTTSEG北京邮电大学通信软件工程中心识别用例从参与者角度出发，识别每类参与者在系统中要实现的目标基本业务过程基本业务过程（EBP，ElementaryBusinessProcess）是指由一个人在某个时间某个地点执行的一项任务，这项任务是对某一业务事件的反应，而且能够增加可以度量的业务价值，并且能够保持数据状态的一致。进行用例分析时，应该专注于EBP级别的用例，但是当一个子功能在多个用户目标级别用例中重复出现，或这个子功能是多个用户目标级别用例的前置条件，如“验证用户身份”、“记录日志”等，则可以定义一个用例来表示该子功能。©2008

BUPTTSEG北京邮电大学通信软件工程中心基本业务过程基本业务过程（EBP，ElementaryB用例描述用例描述的目标是将用例的功能和应用场景描述清楚，包括用例在何时开始，何时结束参与者何时与系统交互交互什么内容所有可能的交互场景对用例的描述，可以用自然语言，也可以采用用户自定义的语言。为了更清楚地说明问题，也可以采用面向对象的类图、交互图、状态图或活动图来做进一步的描述。

©2008

BUPTTSEG北京邮电大学通信软件工程中心用例描述用例描述的目标是将用例的功能和应用场景描述清楚，包括用例描述模板用例编号:每一个用例一个唯一的编号，方便在文档中索引。

用例名称:(状语＋）动词＋（定语＋）宾语，体现参与者的目标。

范围：应用的软件系统范围

级别：企业目标级别/用户目标级别/子系统目标级别

主要参与者:调用系统服务来完成目标的主要参与者

项目相关人员及其兴趣:

用户应包含满足所有相关人员兴趣的内容

前置条件:规定了在用例中的一个场景开始之前必须为“真”的条件。

后置条件：规定了用例成功结束后必须为“真”的条件。

主要成功场景:（基本路径）描述了能够满足项目相关人员兴趣的一个典型的成功路径。不包括条件和分支

1．

……

n．

扩展（或替代流程）:（备选路径）说明了基本路径以外的所有其他场景或分支

*a.描述任何一个步骤都有可能发生的条件，前边加*5a.对基本路径中某个步骤的扩展描述，前边加基本路径编号

特殊需求：与用例相关的非功能性需求技术与数据的变化列表：输入输出方式上的变化以及数据格式的变化。发生频率：用例执行的频率。待解决的问题：不清楚的、尚待解决的问题可集中在此进行罗列©2008

BUPTTSEG北京邮电大学通信软件工程中心用例描述模板用例编号:每一个用例一个唯一的编号，方便在文档中用例之间的关系包含关系用例A在其内部说明的某一位置上显式地使用用例B行为的结果，成为用例A包含用例B。包含关系图示表示如下左图。避免用例中相同功能的重复描述；避免过长的用例。扩展关系在不能改变已有用例的情况下，扩展用例的功能。扩展用例中必须包含触发和扩展点说明。扩展管理的图示表示如下右图。基用例被包含的用例《include》基用例扩展用例《extend》©2008

BUPTTSEG北京邮电大学通信软件工程中心用例之间的关系包含关系《include》《extend》©用例的包含关系举例假设在一个旅游电子商务网站系统中，有如下用例：购买机票预定酒店在这两个用例中，都有一个环节是“填写联系资料”，则可以将“填写联系资料”抽象为一个独立的用例，在上述用例中包含该用例，局部用例图如下图所示：购买机票填写联系资料预定酒店《include》《include》©2008

BUPTTSEG北京邮电大学通信软件工程中心用例的包含关系举例假设在一个旅游电子商务网站系统中，有如下用用例1：购买机票主要成功场景：1.顾客输入航班查询条件；2.系统显示查询结果；……11.顾客填写联系方式，包含填写联系资料用例。12.顾客选择信用卡支付，填写信用卡信息。用例2：预订酒店主要成功场景：1.顾客输入酒店查询条件；2.系统显示查询结果；3．顾客填写入住时间；……8.顾客填写联系方式，包含填写联系资料用例。用例10：填写联系资料级别：子功能主要成功场景：1.顾客在联系方式界面内输入办公电话、手机、Email、邮寄地址和邮箱，点击提交。2.系统验证上述信息格式有效。扩展（或替代流程）：2a.系统发现有必填信息没有填写1.系统给出提示信息；2.顾客填写信息，回到主要成功场景的步骤2。2b.系统验证信息格式不正确1.系统给出提示信息；2.顾客重新填写信息，回到主要成功