638_用例驱动的需求分析方法

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