《8_用例驱动的需求分析方法.pdf》由会员分享，可在线阅读，更多相关《8_用例驱动的需求分析方法.pdf（40页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、软件工程王忠杰2011年4月7日软件工程第三章 需求工程8用例驱动的需求分析方法8用例驱动的需求分析方法主要内容8.1结构化分析方法的不足结构化分析方法的不足8.2用例是什么？用例是什么？8.3用例建模的基本过程用例建模的基本过程8.4用例模型的提交物用例模型的提交物软件工程8.1结构化分析方法8用例驱动的需求分析方法8.1结构化分析方法 结构化分析方法：从数据的结构化分析方法：从数据的“输入加工输出输入加工输出”着眼，以着眼，以“自顶向下自顶向下”的方式进行功能的分解的方式进行功能的分解 主要描述手段：主要描述手段：DFD+DD学生教师教务部课程安排注册请求1 安排课表2 学生注册3产生班级
2、列表班级列表提供的课程学生信息库课程注册信息课程安排数据这种方法有什么缺陷？8用例驱动的需求分析方法结构化分析方法 缺陷：缺陷：非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。8用例驱动的需求分析方法一种新的需求分析技术：用例查看报告学生注册课程登录选择所教的课程提交成绩教授注册员财务系统维护教授信息维护学生信息关闭注册课程目录系统软件工程8.2什么是用例(UseCase)？8用例驱动的需求分析方法8.2什么是
3、用例(UseCase)？用例用例(UseCase)：表示系统所提供的服务或可执行的某种行为：表示系统所提供的服务或可执行的某种行为 定义了系统是如何被参与者所使用的，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段“对话”。用例的概念在1986年由Ivar Jacobson正式提出之后被广泛接受，迅速发展，已成为OO、UML、RUP的标准规范和方法。8用例驱动的需求分析方法什么是用例(UseCase)？Use case 用例：站在用户角度定义软件系统的外部特征用例：站在用户角度定义软件系统的外部特征 四大特征：四大特征：行为序列(sequencesofactions)：一个用
4、例由一组可产生某些特定结果的行为构成，这些行为是不可再分解的(接收用户输入、执行、产生结果)系统执行(systemperforms)：系统为外部角色提供服务；可观测到的、有价值的结果(observableresultofvalue)：用例必须对用户产生价值；特定的角色(particularactor)：某人、某台设备、某外部系统、等等，能够触发某些行为。8用例驱动的需求分析方法用例方法的基本思想 用例方法的基本思想：从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的。用例方法的基本思想：从用户的角度来看，他们并不想了解
5、系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的。用例模型主要由以下模型元素构成：用例模型主要由以下模型元素构成：参与者(Actor)：存在于被定义系统外部并与该系统发生交互的人或其他系统，代表系统的使用者或使用环境。用例(UseCase)通讯关联(CommunicationAssociation)：用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务(用例)、系统所提供的服务(用例)是被哪些参与者所使用的。参与者用例通讯关联8用例驱动的需求分析方法示例：ATM系统的用例 参与者：银行客户参与者：银行客户 用例：银行客户使用自动提
6、款机来进行银行帐户的查询、提款和转帐交易用例：银行客户使用自动提款机来进行银行帐户的查询、提款和转帐交易银行客户查询取款转帐8用例驱动的需求分析方法关于“通讯关联”的几点说明 通讯关联表示的是参与者和用例之间的关系：通讯关联表示的是参与者和用例之间的关系：箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。通讯关联不表示在参与者和用例之间的信息流，并且信息流向是双向的，它与通讯关联箭头所指的方向没有关系。参与者用例通讯关联8用例驱动的需求分析方法用例的内部剖析 用例用例=椭圆椭圆+名字？名字？NO！Use
7、caseName of the Use Case(用例的名字用例的名字)Description(描述)Actor(s)(参与者)Flow of events(事件流)Basic flow(常规流)Event 1(事件)Event 2Alternate flow(备选流)Pre-conditions(前置条件)Post-conditions(后置条件)8用例驱动的需求分析方法用例方法的优点 系统被看作是一个黑箱，并不关心系统内部是如何完成它所提供的功能的。系统被看作是一个黑箱，并不关心系统内部是如何完成它所提供的功能的。首先描述了被定义系统有哪些外部使用者首先描述了被定义系统有哪些外部使用者(抽
8、象为抽象为Actor)、这些使用者与被定义系统发生交互；、这些使用者与被定义系统发生交互；针对每一参与者，又描述了系统为这些参与者提供了什么样的服务针对每一参与者，又描述了系统为这些参与者提供了什么样的服务(抽象成为抽象成为UseCase)、或者说系统是如何被这些参与者使用的；、或者说系统是如何被这些参与者使用的；8用例驱动的需求分析方法用例方法的优点 用例模型容易构建、也容易阅读；用例模型容易构建、也容易阅读；完全站在用户的角度上，从系统外部来描述功能；完全站在用户的角度上，从系统外部来描述功能；帮助系统的最终用户参与到需求分析过程中来，其需求更容易表达出来；帮助系统的最终用户参与到需求分析
9、过程中来，其需求更容易表达出来；软件工程8.3用例建模的基本过程8用例驱动的需求分析方法8.3用例建模的基本过程 Step1：识别并描述参与者：识别并描述参与者(actor)；Step2：识别用例：识别用例(usecase)，并给出简要描述；，并给出简要描述；Step3：识别参与者与角色之间的通讯关联：识别参与者与角色之间的通讯关联(Association)；Step4：给出每一个用例的详细描述：给出每一个用例的详细描述 Step5：细化用例模型：细化用例模型8用例驱动的需求分析方法Step1：识别并描述参与者 通过以下问题来识别通过以下问题来识别Actor：谁使用这个系统的功能？谁从该系统获
10、得信息？谁向该系统提供信息？该系统需要访问(读写)那些外部硬件设备？谁来负责维护和管理这个系统以保证其正常运行？该系统需要与其他系统进行交互吗？参与者8用例驱动的需求分析方法识别并描述参与者 例例1：对一个图书馆管理系统来说，有哪些参与者？：对一个图书馆管理系统来说，有哪些参与者？普通读者 图书管理员 例例2：对：对ATM系统来说，有哪些参与者？系统来说，有哪些参与者？银行客户 ATM维护人员 后台服务器普通读者图书管理员银行客户维护人员后台服务器8用例驱动的需求分析方法特殊的参与者：系统时钟 有时候需要在系统内部定时的执行一些操作，如检测系统资源使用情况、定期生成统计报表等等；有时候需要在系
11、统内部定时的执行一些操作，如检测系统资源使用情况、定期生成统计报表等等；但这些操作并不是由外部的人或系统触发的；但这些操作并不是由外部的人或系统触发的；对于这种情况，可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作；对于这种情况，可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作；从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。系统时钟周期性任务触发8用例驱动的需求分析方法Step2：识别用例(usecase)找到参与者之后，据此来确定系统的用例
12、，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。找到参与者之后，据此来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手寻找用例可以从以下问题入手(针对每一个参与者针对每一个参与者)：参与者使用该系统执行什么任务？参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？参与者是否会将外部的某些事件通知给该系统？系统是否会将内部的某些事件通知该参与者？Use case8用例驱动的需求分析方法识别用例 例例1：对图书馆管理系统来说，有哪些用例？：对图书馆管理系统来说，
13、有哪些用例？图书管理员 登录 管理读者信息 管理图书信息 登记借书 登记还书 例例2：对：对ATM系统来说，有哪些参与者？系统来说，有哪些参与者？银行客户 查询 取款 转装 普通读者：登录 预订图书 取消预订 查询浏览图书信息 ATM维护人员 维护系统 后台服务器 周期性操作8用例驱动的需求分析方法识别用例的几点注意事项 用例必须是由某一个用例必须是由某一个actor触发而产生的活动，即每个用例至少应该涉及一个触发而产生的活动，即每个用例至少应该涉及一个actor。如果存在与如果存在与actor不进行交互的用例，需要将其并入其他用例，或者是检查该用例相对应的参与者是否被遗漏。不进行交互的用例，
14、需要将其并入其他用例，或者是检查该用例相对应的参与者是否被遗漏。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在：反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在：仔细考虑该参与者是如何与系统发生对话的；由参与者确定一个新的用例；该参与者是一个多余的模型元素，应该将其删除。8用例驱动的需求分析方法Step3：识别参与者与角色之间的通讯关联银行客户查询取款转帐后台服务器系统时钟周期性任务操作员维护系统普通读者登录查询浏览预订图书图书管理员管理读者取消预订管理图书信息登记借书登记还书8用例驱动的需求分析方法用例规约.用例模型参与者
15、用例Step4：给出用例的详细描述Name of the Use Case(用例的名字用例的名字)Description(描述)Actor(s)(参与者)Flow of events(事件流)Basic flow(常规流)Event 1(事件)Event 2Alternate flow(备选流)Pre-conditions(前置条件)Post-conditions(后置条件)单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息。单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图形上的信息。8用例驱动的需求分析方法事件流 用例的事件流：用例的事件流：说明用例如何启动，
16、即哪些参与者在何种情况下启动用例？说明参与者与用例之间的信息处理过程；说明用例在不同条件下可以选择执行的多种方案；说明用例在什么情况下才能被视作完成；分为常规流和备选流两类：分为常规流和备选流两类：常规流：描述该用例最正常的一种场景，系统执行一系列活动步骤来响应参与者提出的服务请求；备选流：负责描述用例执行过程中异常的或偶尔发生的一些情况。8用例驱动的需求分析方法常规事件流 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。用一句简短的标题来概括每一步骤的主要内容。用一句简短的标题来概括每一步骤的主要内容。对每一步骤，从正反两个方面来描
17、述对每一步骤，从正反两个方面来描述 参与者向系统提交了什么信息；对此系统有什么样的响应。Step 1Step 2Step 3Step 4Step 5Step 3aStep 3bStep 3c8用例驱动的需求分析方法备选事件流 备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容。备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容。起点：该备选流从事件流的哪一步开始；条件：在什么条件下会触发该备选流；动作：系统在该备选流下会采取哪些动作；恢复：该备选流结束之后，该用例应如何继续执行。Step 1Step 2Step 3Step 4Step 5Step 3aSte
18、p 3bStep 3c8用例驱动的需求分析方法案例用例描述用例：登记借书用例：登记借书1.目标：本用例允许图书管理员登记普通读者的借书记录目标：本用例允许图书管理员登记普通读者的借书记录2事件流：事件流：2.1常规流程当读者希望借书、图书管理员准备登记有关的借书记录时，本用例开始执行。常规流程当读者希望借书、图书管理员准备登记有关的借书记录时，本用例开始执行。(1)系统要求管理员输入读者的注册号和所借图书号；(2)图书管理员输入信息后，系统产生一个唯一的借书记录号；(3)系统显示新生成的借书记录；(4)图书管理员确认后，系统增加一个新的借书记录2.2备选流程备选流程(1)读者没有注册在主流程中
19、，如果系统没有读者的注册信息，系统将显示错误信息，用例结束；读者没有注册在主流程中，如果系统没有读者的注册信息，系统将显示错误信息，用例结束；(2)所借图书不存在在主流程中，如果所借图书已被借出或者系统中无该图书，系统将显示错误信息，用例结束。所借图书不存在在主流程中，如果所借图书已被借出或者系统中无该图书，系统将显示错误信息，用例结束。3前提条件：用例开始前，图书管理员必须在系统登录成功；前提条件：用例开始前，图书管理员必须在系统登录成功；4后置条件：如果用例执行成功，该读者的借书记录被更新，否则，系统状态不变。后置条件：如果用例执行成功，该读者的借书记录被更新，否则，系统状态不变。8用例驱
20、动的需求分析方法Step5：细化用例模型 在一般的用例图中，只需表述参与者和用例之间的通讯关联。在一般的用例图中，只需表述参与者和用例之间的通讯关联。除此之外，还可以描述：除此之外，还可以描述：参与者与参与者之间的泛化(generalization)用例和用例之间的包含(include)用例和用例之间的扩展(extend)用例和用例之间的泛化(generalization)关系 利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来复用，使得用例模型更易于维护。利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来复用，使得用例模型更易于维护。8用例驱动的需求分析方法参与者之间的关系
21、参与者之间可以有泛化参与者之间可以有泛化(Generalization)关系。关系。普通用户常规操作管理操作配置操作系统维护员管理员用户常规操作管理操作配置操作系统维护员管理员actor 2actor 18用例驱动的需求分析方法用例之间的关系：包含(include)“包含关系包含关系”是通过在关联关系上加入是通过在关联关系上加入标记来表示；标记来表示；语义：用例语义：用例1会用到用例会用到用例2，用例，用例2的事件流将被插入到用例的事件流将被插入到用例1的事件流中。的事件流中。用例1用例2银行客户查询取款转帐打印回执8用例驱动的需求分析方法用例之间的关系：扩展(extend)“扩展关系扩展关系
22、”是通过在关联关系上加入是通过在关联关系上加入标记来表示；标记来表示；语义：用例语义：用例2在某些特定情况下会用到用例在某些特定情况下会用到用例1，此时，用例，此时，用例1的事件流将被插入到用例的事件流将被插入到用例2的事件流中。的事件流中。用例1用例2银行客户打电话呼叫等待呼叫转移8用例驱动的需求分析方法用例之间的关系：扩展(extend)常规流：常规流：1如果应答方无应答，进行呼叫转移常规流：如果应答方无应答，进行呼叫转移常规流：1如果应答方正忙，用铃声提示应答方并保持拨号呼叫常规流：如果应答方正忙，用铃声提示应答方并保持拨号呼叫常规流：1拨号拨号2建立通话链路建立通话链路3通话通话4挂机
23、挂机打电话呼叫等待呼叫转移实际上相当于第一个用例的“备选流”8用例驱动的需求分析方法用例之间的关系：泛化(generalization)采购员采购物料采购钢材采购办公用品用例1用例2 当多个用例共同拥有一种类似的结构和行为的时候，可将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。当多个用例共同拥有一种类似的结构和行为的时候，可将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用例继承了父用例所有的结构、行为和关系。子用例继承了父用例所有的结构、行为和关系。8用例驱动的需求分析方法“用例的关系”参与者与参与者之间的泛化参与者与参与者之间的泛化(generalizati
24、on)用例和用例之间的包含用例和用例之间的包含(include)用例和用例之间的扩展用例和用例之间的扩展(extend)用例和用例之间的泛化用例和用例之间的泛化(generalization)关系关系 为什么要引入上述关系？有什么优越性？为什么要引入上述关系？有什么优越性？软件工程8.4用例模型的提交物8用例驱动的需求分析方法用例模型的提交物 1用例模型用例模型 2每个用例的详细描述每个用例的详细描述 3术语表：所用到的术语说明术语表：所用到的术语说明 4补充规约：非功能性需求的说明补充规约：非功能性需求的说明用例规约.用例模型参与者用例8用例驱动的需求分析方法记录一些全局性的功能需求、非功能性需求和设计约束等补充规约术语表用例规约.用例模型参与者用例用例图描述参与者与用例间的关系用例规约描述每一个用例的细节信息记录一些系统需求相关的术语软件工程结束2011年4月7日