《[工学]8_用例驱动的需求分析方法》由会员分享，可在线阅读，更多相关《[工学]8_用例驱动的需求分析方法（40页珍藏版）》请在金锄头文库上搜索。
1、软件工程王忠杰 2011年4月7日软件工程 第三章 需求工程 8 用例驱动的需求分析方法8 用例驱动的需求分析方法主要内容8.1 结构化分析方法的不足结构化分析方法的不足8.2 用例是什么？用例是什么？8.3 用例建模的基本过程用例建模的基本过程8.4 用例模型的提交物用例模型的提交物软件工程8.1 结构化分析方法8 用例驱动的需求分析方法8.1 结构化分析方法 结构化分析方法：从数据的结构化分析方法：从数据的“输入加工输出输入加工输出”着眼，以着眼，以“自顶向下自顶向下” 的方式进行功能的分解的方式进行功能的分解 主要描述手段：主要描述手段：DFD+DD学生教师教务部课程安排注册请求1 安排
2、课表2 学生注册3 产生班级 列表班级列表 提供的课程学生信息库课程注册信息课程安排数据这种方法有什么缺陷？8 用例驱动的需求分析方法结构化分析方法 缺陷：缺陷： 非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计 在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？ 分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能 项是如何相互关联来实现一个完成的系统服务的。8 用例驱动的需求分析方法一种新的需求分析技术：用例查看报告学生注册课程登录选择所教的课程提交成绩教授注册员财务系统维护教授信息维护学生信息关闭注册课程目录系统软件工程8.2 什么是用例(Use
3、Case)？8 用例驱动的需求分析方法8.2 什么是用例(Use Case)？ 用例用例(Use Case)：表示系统所提供的服务或可执行的某种行为：表示系统所提供的服务或可执行的某种行为 定义了系统是如何被参与者所使用的，描述了参与者为了使用系统所提供的 某一完整功能而与系统之间发生的一段“对话”。 用例的概念在1986年由Ivar Jacobson正式提出之后被广泛接受，迅速发展， 已成为OO、UML、RUP的标准规范和方法。8 用例驱动的需求分析方法什么是用例(Use Case)？Use case 用例：站在用户角度定义软件系统的外部特征用例：站在用户角度定义软件系统的外部特征 四大特征
4、：四大特征： 行为序列(sequences of actions)：一个用例由一组可产生某些特定结果的行为 构成，这些行为是不可再分解的(接收用户输入、执行、产生结果) 系统执行(system performs)：系统为外部角色提供服务； 可观测到的、有价值的结果(observable result of value)：用例必须对用户产 生价值； 特定的角色(particular actor)：某人、某台设备、某外部系统、等等，能够触 发某些行为。8 用例驱动的需求分析方法用例方法的基本思想 用例方法的基本思想：从用户的角度来看，他们并不想了解系统的内 部结构和设计，他们所关心的是系统所能提供
5、的服务，也就是被开发 出来的系统将是如何被使用的。用例方法的基本思想：从用户的角度来看，他们并不想了解系统的内 部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发 出来的系统将是如何被使用的。 用例模型主要由以下模型元素构成：用例模型主要由以下模型元素构成： 参与者(Actor) ：存在于被定义系统外部并与该系统发生交互的人或其他系 统，代表系统的使用者或使用环境。 用例(Use Case) 通讯关联(Communication Association) ：用于表示参与者和用例之间的对应 关系，它表示参与者使用了系统中的哪些服务(用例)、系统所提供的服务(用 例)是被哪些参与者所使用
6、的。参与者用例通讯关联8 用例驱动的需求分析方法示例：ATM系统的用例 参与者：银行客户参与者：银行客户 用例：银行客户使用自动提款机来进行银行帐户的查询、提款和转帐 交易用例：银行客户使用自动提款机来进行银行帐户的查询、提款和转帐 交易银行客户查询取款转帐8 用例驱动的需求分析方法关于“通讯关联”的几点说明 通讯关联表示的是参与者和用例之间的关系：通讯关联表示的是参与者和用例之间的关系： 箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被 动接受者； 如果不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。 通讯关联不表示在参与者和用例之间的信息流，并且信息流向是双向
7、的，它 与通讯关联箭头所指的方向没有关系。参与者用例通讯关联8 用例驱动的需求分析方法用例的内部剖析 用例用例= 椭圆椭圆 + 名字？名字？ NO！Use caseName of the Use Case (用例的名字用例的名字)Description (描述) Actor(s) (参与者) Flow of events(事件流) Basic flow(常规流) Event 1 (事件) Event 2 Alternate flow(备选流) Pre-conditions (前置条件) Post-conditions (后置条件) 8 用例驱动的需求分析方法用例方法的优点 系统被看作是一个黑箱
8、，并不关心系统内部是如何完成它所提供的功 能的。系统被看作是一个黑箱，并不关心系统内部是如何完成它所提供的功 能的。 首先描述了被定义系统有哪些外部使用者首先描述了被定义系统有哪些外部使用者(抽象为抽象为Actor)、这些使用者 与被定义系统发生交互；、这些使用者 与被定义系统发生交互； 针对每一参与者，又描述了系统为这些参与者提供了什么样的服务针对每一参与者，又描述了系统为这些参与者提供了什么样的服务(抽 象成为抽 象成为Use Case)、或者说系统是如何被这些参与者使用的；、或者说系统是如何被这些参与者使用的；8 用例驱动的需求分析方法用例方法的优点 用例模型容易构建、也容易阅读；用例模
9、型容易构建、也容易阅读； 完全站在用户的角度上，从系统外部来描述功能；完全站在用户的角度上，从系统外部来描述功能； 帮助系统的最终用户参与到需求分析过程中来，其需求更容易表达出 来；帮助系统的最终用户参与到需求分析过程中来，其需求更容易表达出 来；软件工程8.3 用例建模的基本过程8 用例驱动的需求分析方法8.3 用例建模的基本过程 Step 1：识别并描述参与者：识别并描述参与者(actor)； Step 2：识别用例：识别用例(use case)，并给出简要描述；，并给出简要描述； Step 3：识别参与者与角色之间的通讯关联：识别参与者与角色之间的通讯关联(Association)； S
10、tep 4：给出每一个用例的详细描述：给出每一个用例的详细描述 Step 5：细化用例模型：细化用例模型8 用例驱动的需求分析方法Step 1：识别并描述参与者 通过以下问题来识别通过以下问题来识别Actor： 谁使用这个系统的功能？ 谁从该系统获得信息？ 谁向该系统提供信息？ 该系统需要访问(读写)那些外部硬件设备？ 谁来负责维护和管理这个系统以保证其正常运行？ 该系统需要与其他系统进行交互吗？参与者8 用例驱动的需求分析方法识别并描述参与者 例例1：对一个图书馆管理系统来说，有哪些参与者？：对一个图书馆管理系统来说，有哪些参与者？ 普通读者 图书管理员 例例2：对：对ATM系统来说，有哪些
11、参与者？系统来说，有哪些参与者？ 银行客户 ATM维护人员 后台服务器普通读者图书管理员银行客户维护人员后台服务器8 用例驱动的需求分析方法特殊的参与者：系统时钟 有时候需要在系统内部定时的执行一些操作，如检测系统资源使用情 况、定期生成统计报表等等；有时候需要在系统内部定时的执行一些操作，如检测系统资源使用情 况、定期生成统计报表等等； 但这些操作并不是由外部的人或系统触发的；但这些操作并不是由外部的人或系统触发的； 对于这种情况，可以抽象出一个系统时钟或定时器参与者，利用该参 与者来触发这一类定时操作；对于这种情况，可以抽象出一个系统时钟或定时器参与者，利用该参 与者来触发这一类定时操作；
12、 从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统 所提供的用例对话。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统 所提供的用例对话。系统时钟周期性任务触发8 用例驱动的需求分析方法Step 2：识别用例(use case) 找到参与者之后，据此来确定系统的用例，主要是看各参与者需要系 统提供什么样的服务，或者说参与者是如何使用系统的。找到参与者之后，据此来确定系统的用例，主要是看各参与者需要系 统提供什么样的服务，或者说参与者是如何使用系统的。 寻找用例可以从以下问题入手寻找用例可以从以下问题入手(针对每一个参与者针对每一个参与者)： 参与者使用该系统执行什么任务
13、？ 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话， 参与者又是如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？Use case8 用例驱动的需求分析方法识别用例 例例1：对图书馆管理系统来说，有哪些用例？：对图书馆管理系统来说，有哪些用例？ 图书管理员 登录 管理读者信息 管理图书信息 登记借书 登记还书 例例2：对：对ATM系统来说，有哪些参与者？系统来说，有哪些参与者？ 银行客户 查询 取款 转装 普通读者： 登录 预订图书 取消预订 查询浏览图书信息 ATM维护人员 维护系统 后台服务器 周期性操作8 用例驱
14、动的需求分析方法识别用例的几点注意事项 用例必须是由某一个用例必须是由某一个actor触发而产生的活动，即每个用例至少应该涉 及一个触发而产生的活动，即每个用例至少应该涉 及一个actor。 如果存在与如果存在与actor不进行交互的用例，需要将其并入其他用例，或者是 检查该用例相对应的参与者是否被遗漏。不进行交互的用例，需要将其并入其他用例，或者是 检查该用例相对应的参与者是否被遗漏。 反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何 用例相关联的参与者存在：反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何 用例相关联的参与者存在： 仔细考虑该参与者是如何与系统发生对
15、话的； 由参与者确定一个新的用例； 该参与者是一个多余的模型元素，应该将其删除。8 用例驱动的需求分析方法Step 3：识别参与者与角色之间的通讯关联银行客户查询取款转帐后台服务器系统时钟周期性任务操作员维护系统普通读者登录查询浏览预订图书图书管理员管理读者取消预订管理图书信息登记借书登记还书8 用例驱动的需求分析方法用例规约.用例模型参与者用例Step 4：给出用例的详细描述Name of the Use Case (用例的名字用例的名字)Description (描述) Actor(s) (参与者) Flow of events(事件流) Basic flow(常规流) Event 1 (
16、事件) Event 2 Alternate flow(备选流) Pre-conditions (前置条件) Post-conditions (后置条件) 单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图 形上的信息。单纯的用例图并不能描述完整的信息，需要用文字描述不能反映在图 形上的信息。8 用例驱动的需求分析方法事件流 用例的事件流：用例的事件流： 说明用例如何启动，即哪些参与者在何种情况下启动用例？ 说明参与者与用例之间的信息处理过程； 说明用例在不同条件下可以选择执行的多种方案； 说明用例在什么情况下才能被视作完成； 分为常规流和备选流两类：分为常规流和备选流两类： 常规流：描述该用例最正常的一种场景，系统执行一系列活动步骤来响 应参与者提出的服务请求； 备选流：负责描述
