中科院需求工程 基于情景的方法.ppt

需 求 工 程,金芝中国科学院数学与系统科学研究院,第七讲：基于情景的方法,方法概述情景分析和验证情景表示一个基于情景的需求分析工具情景研究新进展小结,方法概述,情景：一般性定义,The outline or script of a film,with details of scenes or an imagined sequence of future events Oxford English DictionaryScenarios are example“stories”of normal events and critical incidents that represent the types of situations with which performers must work and use the system McGraw K.,1994,从系统进化看情景方法的提出,重构当前系统蕴涵的概念和理念在概念层定义想要的改变实现要改变概念构成新的系统与此同时，考虑遗产系统,从系统进化看情景方法的提出,纯模型方法的问题能肯定这个模型真的反映了对变化的理解吗？基于情景的方法提供一个现实的，处于模型和现实之间的中间层抽象，可以克服这个问题可能情景的数量远远多于给定系统的模型的数量，许多研究者认识到需要一个目标层次导出基于情景的处理,从系统进化看情景方法的提出,情景的使用：与系统相关,使用情景作为系统需求的表示，改善开发者和用户之间的沟通发现用户的需要将系统的使用方式嵌入系统开发过程中系统地研究测定系统的行为（包括正常行为和异常行为）与UML的用例紧密相关,情景的作用以及与需求的关系,情景：与系统相关的定义,非形式的定义：完成系统预期任务的一个特定执行实例所包含动作和事件的序列 开发情景的目的：模拟运作过程情景的内容，关于：可能的出现与这些出现相关的假设可能的机会和风险行为的过程,三种不同目的的情景,描述性的（descriptive）情景通过使系统分析师和用户共同遍历某一流程而理解流程相关的操作、参与者以及触发流程的事件等因素。描述性的情景有助于对流程执行的方式、流程的参与者以及流程启动的方式和条件进行分类。解释性的（explanatory）情景确定系统要解决的问题并分析这些问题出现的基本原理。这类情景揭示为什么现实世界中会发生某些事件？是什么导致这些事件的发生？什么是这些事件的动因？以及哪些是经常发生的和需要进行处理的事件？解释性情景的描述要开发的系统所要求具有的功能。探索性情景（exploratory）用于将需求与解决方案相关联，对存在多种满足系统需求的方案时非常有用，主要用于考查和评估这些方案，以得出其中最正确的方案。,不同抽象层次上的情景,实例情景包含带实际参数值的特定名称或事件。这类情景描述特定应用实例，作为讨论需求的基础，如：发生了什么，为什么发生以及如何发生的。类型情景不定义单个情景实例而是定义情景实例的类型。因此类型情景不会涉及参与者王晓红而只会涉及到顾客。类型情景的每一次执行都是一个实例情景。混合型情景中有些情景在实例级有些在类型级。,不同的情景表示,现实世界情景：现实世界事件发生序列，表示为叙事性文本、影象等，完全非形式表示设计世界情景：想象中的目标系统相关的事件序列，表示为设计的故事、动画型的动作序列，可能需要是结构化表示，如表格和情景文本等，或形式化表示模型情景：按照模型的语法语义要求的事件序列，采用形式化表示，如基于正则表达式或自动机等,情景在需求和设计中的作用,情景的优点和缺点,将需求陈述和推理建立在具有一定细节的实例上，利于需求抽取关注现实世界，解决具体的现实问题中的困难。质问抽象模型难，判断具体例子中的问题容易情景可以作为测试案例测试规格说明和设计模型,从情景中泛化出抽象模型的过程不好理解（但结合情景的抽象模型上的推理却帮助理解）情景可能会导致对频繁出现的事件的过度关注，对出现不够频繁的事件的忽略（必须保证情景的覆盖面）情景越多越好，但过多的情景增加开发的代价（情景集合的完整性和恰当性）情景主要集中在功能性需求上,基于情景的需求分析,情景抽取（面谈法）,Can you give me an example of a situation that illustrates problems with information capture and transfer?,Sure,I remember trying to get the 1994 quality report out.The information was there,but,情景描述的主要成分,目标和关键成功因素物理上下文和逻辑上下文组成情景的主要事件和活动涉及的执行者和其他参与者要使用的信息和资源要考虑的约束和要使用规则需要作决策的点、要考虑的约束、要应用的规则性能问题和提高的机会,比如：创伤诊治情景的目标“让病人得到及时并且合适的干预、运送和诊治”，可能的子目标包括“管理紧急医疗资源，保证能处理多起创伤事故”，“避免非重创病人运送到创伤诊治中心”，或者“选择应用适当的诊治措施”,比如，适当分布诊治中心（保证及时响应；创伤病人在诊治的黄金时间到达诊治中心；诊治中心对任何可能发生创伤的地点来说都是在规定时间内可达的；救治人员有能力判别创伤并快速进行干预；救治人员必须选择适当的运送方式,物理上下文：影响情景进行的物理条件，比如，情景中描述的执行者和其他角色（包括使用的设备）处于的地点，活动发生的地点，以及它们之间的交互逻辑上下文：事件发生的条件、业务情形、等，非物理世界的,情景中出现的基本过程、功能、活动，抽象出高层事件过程、功能/高层事件到达事故现场/场景评估、初步评估、决定救援需求治疗类选法/优先级分配、计划运送和干预救治/运送方案选择、处理和干预,情景描述的主要成分,目标和关键成功因素物理上下文和逻辑上下文组成情景的主要事件和活动涉及的执行者和其他参与者要使用的信息和资源要考虑的约束和要使用规则需要作决策的点、要考虑的约束、要应用的规则性能问题和提高的机会,比如：创伤诊治情景的目标“让病人得到及时并且合适的干预、运送和诊治”，可能的子目标包括“管理紧急医疗资源，保证能处理多起创伤事故”，“避免非重创病人运送到创伤诊治中心”，或者“选择应用适当的诊治措施”,比如，适当分布诊治中心（保证及时响应；创伤病人在诊治的黄金时间到达诊治中心；诊治中心对任何可能发生创伤的地点来说都是在规定时间内可达的；救治人员有能力判别创伤并快速进行干预；救治人员必须选择适当的运送方式,物理上下文：影响情景进行的物理条件，比如，情景中描述的执行者和其他角色（包括使用的设备）处于的地点，活动发生的地点，以及它们之间的交互逻辑上下文：事件发生的条件、业务情形、等，非物理世界的,情景中出现的基本过程、功能、活动，抽象出高层事件过程、功能/高层事件到达事故现场/场景评估、初步评估、决定救援需求治疗类选法/优先级分配、计划运送和干预救治/运送方案选择、处理和干预,情景分析,情景：用于描述一个存在系统以及它的环境的事实，包括主体(Agents)的行为和进行系统需求发现和验证的足够的上下文信息很多情况下，作为UML用例图的扩展和补充情景是系统使用的实例，常用于作为测试数据，和通过研究事件之间的关系来验证需求,基于情景的需求分析,分析用户目标，检查是否需要系统功能的支持,得出系统目标，并引出系统功能需求,识别系统和用户以及环境的交互,分析交互和所需求的功能，得出对输入事件响应方式,根据输入事件和系统目标，得出系统的输出事件,分析系统输出的用户接受度，以及系统输出事件的影响,分析系统输出是否对用户任务提供必要的支持，并且没有带来不希望的结果,进行涉众性能价格比,用于评估系统输出的影响，以及技术和社会系统的偶合,情景分析：知识表示框架,空间信息和物理环境事实,情景分析：伦敦救护车系统,情景结构模型,情景脚本,情景需求验证：目标分析,目标分析启发式用户目标需要计算机支持吗？如果是，在需求规格说明中增加一条功能需求，否则增加非功能需求目标描述系统应该实现的质量或性能特性吗？这些特性指定了可能不能直接实现的非功能性需求，非功能需求要和帮助实现它们的Agents和活动相关联如果目标不要求计算机支持，它可以由手工过程达到吗？这表明需要为社会系统活动做一个操作过程手册目标需要关于资源和职责的管理决策吗？管理职责目标需要与情景模型中的合适的Agent相连情景目标和它所关联的活动能够完全自动化吗？如果能，则将这部分情景模型转换为需求规格说明，如果只需要部分自动化，则需要模型的进一步细化及其规格说明,情景需求验证：目标分析,公众：得到立即响应，救护车快速到达救护车队：获得事故和发生地点的准确信息，以及完成这项任务的有用指令；尽快赶到事故地点；进行辅助医务处理；尽可能安全快捷地送达医院派遣员：确定事故地点和优先级，计划最近最合适的救护车的派遣；监控呼叫进展；获得呼叫和救护车队状态的精确信息经理：提供有效的服务并缩减代价；优化救护车和车队资源的使用,情景需求验证：目标分析,一些经验教训：许多目标只能由人工活动支持规划和调度是关键的活动，它们依赖于几个目标，而且这些目标分别出自不同的涉众出现目标冲突情况一开始自动调度系统是用于支持派遣任务的，但随着分析的深入，这个支持显得越来越不合适虽然引入自动系统是为了减少人力和提高资源的使用率，但这个系统对车队的支持却很少,情景需求验证：输入事件依赖,通过跟踪所有可能的输入事件，检查环境和系统的依赖关系事件的来源：环境中的Agents，通常是产生系统输入的人环境中引起事件出现的对象，比如，风暴、动物横穿马路、等等对信息系统，大多数事件出自人对实时系统，许多事件源于物理世界或其它系统,情景需求验证：输入事件依赖,对每个输入事件，确定：有系统功能来处理它吗？如果没有，则应该加入新的功能性需求该事件要求系统达到一个目标状态吗？如果是的话，存在一个过程来完成行这个必要的变化吗？该事件蕴涵系统应该维持一个目标状态吗？如果是的话，一旦系统离开了这个状态，系统能否解释？系统能否采取补救行为回到想要的状态？这些问题蕴涵监控正常状态和矫正偏差的功能性需求,情景需求验证：输入事件依赖,事件的可靠性：如果事件没有出现怎么办？系统能继续运行吗？如果这个事件是必需的，系统要报告故障吗？如果事件出现得太早或太晚怎么办？系统对时间敏感吗？来得早的事件可以缓存起来吗？如果可以，缓存多少？来得晚的事件能容忍吗？如果能，系统要停止其它任务来响应它，如果不能，系统要报错吗？如果事件到达的次序不对怎么办？系统是序列相关的吗？如果是，需要缓存错误排序的事件并重新排序吗？如果事件重复出现怎么办？系统能检测出重复吗？如果能，要消除多余的事件吗？如果没有预想到的事件发生了怎么办？系统能够处理未知输入吗？系统能够解释无关的事件并报告吗？如果传错了事件发生了怎么办？系统能够检测出形式正确的事件的内容被破坏了吗？系统能够请求事件发送者重发吗？,情景需求验证：输入事件依赖,主要的三类事件蕴涵不同的系统响应：可以验证发生次序和时间的已知事件：系统需要对照事件历史检测事件次序，并采取错误矫正行为可以在任何时候发生的已知事件：系统需要检查事件发生的可能性，并提供回滚操作帮助矫正用户错误，或者事件不正常出现时提示警告消息未知事件：系统应该继续正确地运行，需要例外捕获过程，或者记录机制，使研究人员可以研究例外事件。,情景需求验证：输入事件依赖,进一步的分析：事件的来源可以跟踪到某个特定个体吗？如果可以，这个个体是否被授权发送这个事件？这个需求蕴涵识别消息来源和个体口令保护的日志。在网络环境下，事件的来源难以检测到，这个要求隐含了对授权协议的需求。其它安全的考虑：事件消息可以被其他人看到吗？如果事件必须保密，则需要加密,情景需求验证：输入事件依赖,伦敦救护车问题呼叫重复：引出识别呼叫者、事故地点和情况的需求，以消除重复不同结果的事件对资源的需求不同：引出分析事故结果的需求情景脚本中的两个报告事件是对报告事件的简化，因为报告事件没发生意味着可能的失效，引出对失效处理的需求派遣员的指令是关键事件，准确的信息更是关键,情景需求验证：分类系统输出,系统输出的形式消息显示对话框语音合成需求说明形式：列表屏幕布局图故事板原型界面,情景需求验证：分类系统输出,五种输出事件类型直接命令：要求人类采取行动的输出信息间接命令：可以是警告消息或者信息显示，它们隐含人类应该采取行动输入请求：提示系统需要用户的输入信息显示：仅仅描述信息，并不隐含需要立即的响应虚拟交互：模拟显示，虚拟世界,情景需求验证：输出需求分析,任务：交叉检索情景和需求规格说明，保证输出在需要的时候被产生提示问题：如果在情景脚本中，一个用户在某个时间点需要某个信息，存在系统功能提供这个信息吗？,情景需求验证：输出需求分析,核对表针对需求规格说明，对每个产生输出的组件，情景中存在相应的对该输出信息的用户需求吗？在情景某个步骤上用户需要的信息，该信息在它需要的时候能产生吗？系统输出和用户任务的偶合依赖于应用的类型，安全系统中要求精确的同步用户需要这个信息是为了支持决策吗？指出输出需求，即系统应该提供信息帮助用户作决策，或者提供执行任务的指令在情景中用户的目的是寻找信息吗？指出信息检索需求,情景需求验证：输出需求分析,进一步的分析（适合性，这是用户想要的吗？）系统输出的信息内容对用户任务或目标来说合适吗？,情景需求验证：输出需求分析,进一步的分析（安全性）谁应该得到这个输出信息？收到信息的人不对怎么办？需要加密功能输出丢失了怎么办？需要登记消息日志、消息重发的功能输出到的太早或太晚怎么办？需要时效控制功能输出到达的次序不对怎么办？需要保证输出顺序的功能如果输出信息不允许流传，需要跟踪输出目的地，获得身份认证等的功能，以保证到达正确的目的地，防止非法访问,情景需求验证：输出需求分析,伦敦救护车问题直接输出：直接命令：派遣员到救护车队的命令信息显示：事故的位置和状态，救护车行驶的情况，车队和呼叫的分配关系,情景需求验证：输出需求分析,伦敦救护车问题系统输出的使用：车队需要交通拥堵和道路状况信息（未提供，因为车队和系统没有直接的交互）派遣员交通拥堵和道路状况信息，以支持其进行正确的决策派遣指令传送的正确性，要求车队身份认证指令丢失导致呼叫无响应，重复指令会导致重复派遣，指令次序错误会引起车队混乱，要求指令通讯的正确无误不正确的指令导致系统混乱，要求交叉检查指令的准确性和正确性,情景需求验证：社会影响分析,困难的任务，因为不知道准确的社会理论，来预计人类用来应对计算机系统的行为缺少足够的特定社会系统的知识来做这个预计缺少稳定的社会环境，使得在系统被够建出来后这个预测仍然有效,情景需求验证：社会影响分析,一些可能的考虑点：评估社会系统和技术系统的偶合度系统输出记数紧偶合加大了二者的依赖程度，导致系统容易出错设计一些自治的子系统来减少偶合度社会系统的文化影响对偶合度的容忍程度，层次式组织结构容易容忍紧偶合，网络化组织适合于松偶合,情景需求验证：社会影响分析,一些可能的考虑点：情景结构模型的不同细化，产生不同的系统边界，导致不同的（人和机器之间）任务分配过多的自动化会削弱人的职责过多的自动化会削弱人对整个系统的意识，导致人对意外处理的能力下降强迫人做他不想做的任务的这种自动化，增加人的抵触情绪强加给人很多新任务的紧偶合自动化，用不自然的方式限制了人类的活动，也会增加人的抵触情绪人与自动系统的偶合应该对用户的知识和技能敏感自动系统的引入不能改变人与人之间的职责关系和权利关系,情景需求验证：社会影响分析,在系统边界确定之后，进行输出结构影响分析，考虑系统输出是否能实现用户目标，授权关系是否清楚，是否没有冲突。信息输出的影响分析：信息输出给每个Agent会增加他的权利吗？会削弱其他Agent的权利吗？输出的信息会被恶意使用吗？,情景需求验证：社会影响分析,情景结构模型用于影响分析，第一步评估命令影响的启发式：系统的这个输出触发了人类Agent负责的一个活动吗？如果是这就是一个直接命令系统的这个输出对人类Agent的一个决策活动是必须的吗？如果是这就是一个间接命令系统的这个输出对人类Agent完成一个活动有帮助吗？如果是这就是一个间接依赖,情景需求验证：社会影响分析,情景结构模型用于影响分析，第二步评估目标、职责、作用和授权等的启发式。对每个输出命令，评估将涉及的Agents：检查Agent的特性确定他们是否具备必要的技能或知识来执行这个任务，如果不是，隐含需要人员选拔或培训检查Agent的作用和任务，如果这个命令给的人错了，隐含需要改变社会系统检查Agent是否能够按时并按合适的方式来响应这个命令，研究制定决策或者执行任务的时间要求,情景需求验证：社会影响分析,情景结构模型用于影响分析，第三步检查用户是否可能接受这个命令：命令会导致组织职责分配的无序吗？要求一个Agent接受一个超出职责范围的决定命令破坏了用户的授权吗？系统需要用户在错误的时间接受一个决定命令改变了人类Agents之间的权利关系吗？命令削弱了一个Agent的权利而增加了另一个Agent的权利,情景需求验证：涉众分析,对每类涉众：新系统降低了他们工作的技能吗？（过度自动化）新系统威胁到他们工作的保密性吗？他们的职责将被新系统削弱吗？（自动化或者职责重新分配）系统影响工作积极性吗？（过度偶合、太不灵活、剥夺自主性、没有提供足够的信息、等）,情景需求验证：涉众分析（案例）,情景需求验证：涉众分析（案例）,情景形式化表示工具,基于时间区间的情景表示严格顺序：ev(endA)ev(endB)and(ev(endA)ev(endB)并发：交替：(ev(startA)occurs)or(ev(startB)occurs)并行：(ev(startA)=ev(startB)and(ev(endA)=ev(endB)同时开始：(ev(startA)=ev(startB)and(ev(endA)not=ev(endB)同时结束：(ev(startA)not=ev(startB)and(ev(endA)=ev(endB),一个基于情景的需求分析工具SCRAM,SCRAM：基于情景的需求分析,情景用来早期原型化抽取需求提供集成的技术，让用户积极参与，得到用户的有效反馈利用情景作为背景讨论设计方案、引出新的需求,SCRAM,传统的面谈法等信息采集技术,为要构造的系统创建早期的想象,通过故事板向用户解释并获取反馈,通过概念展示器和早期原型向用户表现更细的设计,进行情景驱动的,半交互式的证明,开发更全面的功能原型,并继续求精需求,直到原型被所有用户接受,SCRAM：故事面板,概念展示器：上下文情景（例）,本船是一艘现代运输船（3万吨），有36个船员和5个管理人员（国际化），上午10点离开南开普顿，向方向开进，现在位置在，现在的气象条件好，能见度15英里，西北风，风力3级。下午3:10pm，一个船员报告发现在2号船舱发现烟雾，发出火警信号,从船长任务产生情景脚本,研究发生火警的位置，如果必要向船员发出疏散命令如果有，启动自动火警扑灭系统广播命令，让船员开始救火分配初级管理人员领导救火队检查船货，看是否有危险品靠近火警点计划救火策略，考虑危险品和其它灾害发布救火指令，监控救火过程，直到火警消除,SCRAM：概念展示器,从情景脚本到设计问题,情景与UML用例,再论情景的定义,情景是事件的序列从用例的角度看：是穿越用例的一条可能的路径情景是从用例中导出的行为/活动的序列每个用例可能导出多个情景对由多个情景组成的集合进行推理，需要适当的表达手段和推理机制,基于区间的时间推理,基本假设：区间是表示时间的基本单位时间是度量客观事件发生的先后和延续性的一种标准客观事件的发生总是有一个过程区间长度一般不为零有两个时间点：起点t(A)-和终点t(A)+基本假设：时间区间是半开半闭的,七种时间关系,假设A、B表示两个时间区间A在B之前：AB，具体特征：t(A)+t(B)-A等于B：A=B，具体特征：t(A)-=t(B)-，t(A)+=t(B)+A遇上B：A m B，具体特征：t(A)+=t(B)-A交叉B：A o B，具体特征：t(A)-t(B)-t(A)+t(B)+A在B中：A d B，具体特征：t(B)-t(A)-t(A)+t(B)+A开始B：A b B，具体特征：t(A)-=t(B)-t(A)+t(B)+A结束B：A e B，具体特征：t(B)-t(A)-t(A)+=t(B)+,从用例片段到情景,从用例片段到情景,买卖用例中的事件事件A：卖方拿起电话事件B：买方请求报价事件C：交易系统显示价格事件D：卖方拒绝买卖事件E：卖方检索价格信息事件F：,从用例片段到情景,从用例片段到情景,事件之间的时间区间关系A在B之前：t(A)+t(B)-B在C之前：t(B)+t(C)-B在D之前：t(B)+t(D)-B交叉E：t(B)-t(E)-t(B)+t(E)+E交叉C：t(E)-t(C)-t(E)+t(C)+,从用例片段到情景,根据时间关系约束产生可能的情景情景一：t(A)-t(A)+t(B)-t(E)-t(B)+t(E)+t(C)-t(C)+情景二：t(A)-t(A)+t(B)-t(E)-t(B)+t(C)-t(E)+t(C)+情景三：t(A)-t(A)+t(B)-t(B)+t(D)-t(D)+,从用例片段到情景,情景支持的轻量级形式化方法,情景和类模型的一致性检测将情景和类图等结构显式地表示出来，并对所有的图元进行命名定义一些检测的规则，包括可形式检测的规则，如：名一致性规则语法正确性规则引用正确性规则人工检测的规则，如：重叠最小化避免缺少信息内容的对应性信息流的充分性关于领域特性的规则,用于一致性检测的元模型,反例建模,误用用例，misuse case滥用用例，abuse case一个可以被任何人或实体为了破坏系统的进行的行为序列表示系统应该避免的应用场景误用户，misuser触发误用用例的参与者，有意的或无意的,反例建模,误用用例图：关系一般用例中的关系：IncludeExtendGeneralizeAssociation新的关系Mitigate：一个用例能够减少一个误用用例成功的机会Threaten：一个误用用例能够对一个用例产生威胁，比如利用一个用例，或者阻止一个用例，来达到它的目的,反例建模,从误用用例中识别安全需求识别系统中的关键资产对每个关键资产，定义安全目标通过识别想要危害这个系统的系统参与者，来识别每个安全目标的威胁采用风险技术，识别和分析威胁的风险对这些风险定义安全需求,应用情景图（use case maps）,从误用用例中识别安全需求识别系统中的关键资产对每个关键资产，定义安全目标通过识别想要危害这个系统的系统参与者，来识别每个安全目标的威胁采用风险技术，识别和分析威胁的风险对这些风险定义安全需求,应用情景图（use case maps）,一种表示法，图示出与候选系统组件相关的场景路径基于情景的软件工程技术，描述一个或多个用例的职责之间的因果关系用类似路径图的形式显示有关的用例,UCM表示法 基本部分,UCM例:通勤,准备好离开家,在办公室,Responsibility Point,Basic Path(from circle to bar),Component(generic),为什么用应用情景图?,桥接需求和设计之间的建模鸿沟用显式可视化的方式连接行为和结构为高层设计层的体系结构决策提供行为框架一旦体系结构出来后，刻画体系结构层的行为在一个图中表达了很多方面的信息集成了一个情景，便宜推断出潜在的不希望出现的情景交互,为什么用应用情景图?,提供为动态系统建模的能力，这种系统可能在运行时改变情景和结构电子商务应用远程通讯系统简单、直观、易学边设计边文档化不熟悉领域的开发人员学习领域知识的有效工具经过直接的变换就可以转化为消息序列图、系统性能模型和测试用例,应用情景图处于什么位置？,UCM表示法 层次结构,UCM Example:Commuting,readytoleavehome,incubicle,securehome,commute,takeelevator,Dynamic Stub(selection policy),Static Stub,stayhome,UCM表示法 简单插装,UCM Example:Commute-Car(Plug-in),UCM表示法 AND/OR,UCM Example:Commute-Bus(Plug-in),AND Fork,OR Join,OR Fork,AND Join,UCM表示法 动态结构,Generic UCM Example,start,end,Dynamic Responsibilities and Dynamic Components,pool A,pool B,create,create,copy,destroy,destroy,move out,move into,move into,Slot(component),Pool(component),应用情景图的使用,需求捕获体系结构评估验证和特征交互检测到设计和测试的转换,User,Select Destination,The elevator control system case study is adapted from Hassan Gomaas Designing Concurrent,Distributed,And Real-Time Applications with UML(p459-462),copyright Hassan Gomaa 2001,published by Addison Wesley.Used with permission.,需求捕获,User,Arrival Sensor,Service Personnel,Scheduler,Elevator,inelevator,above,below,decide on direction,else,door close,motorup,motordown,moving,at floor,up,down,selectelevator,approachingfloor,not requested,motorstop,requested,door open,at requestedfloor,stationary-memory,switch on,doorclosing-delay,add tolist,on list,alreadyon list,remove from list,Arch.Alternative(I),体系结构评估,User,Service Personnel,Elevator,Scheduler,Status&Plan,Status&Plan,Elev.Control,Elev.Mgr,inelevator,above,below,decide ondirection,else,doorclose,motorup,motordown,moving,at floor,up,down,selectelevator,Arrival Sensor,approachingfloor,not requested,motorstop,door open,stationary-memory,switch on,doorclosing-delay,add tolist,alreadyon list,on list,requested,removefrom list,at requestedfloor,Arch.Alternative(II),体系结构评估,情景验证一般性问题,给定一组捕获非形式化（功能性）需求的情景（形式地）说明情景间的交互可能导致的不希望发生的涌现行为,等等验证,即查找逻辑上的错误并对照非形式的需求进行检查可以采用一些工具和技术,比如功能测试,通过审查进行UCM验证,审查可检测的几个问题选择策略和或分支上的非确定性错误的UCM二义性的UCM,缺少注释将特征情景集成到一起的同时解决特征交互问题剩余的不期望的特征交互需要检测一些特征交互出现在情景桩和选择策略上需要进一步的形式化分析,特征交互,同一个桩的候选插入之间的矛盾（插入的前提条件相同）Call waiting(CW)vs.automatic re-call(ARC),特征交互,不同桩的不同被选的插入之间的不期望的行为（插入的后置条件不同）Originating call screening(OCS)denies call whereas call forward(CF)redirects call to screened number,分析模型构造,源情景模型 目标分析模型Q1.目标语言应该是什么?UCM规格说明?Q2.构造策略应该是什么?分析的方法构建和测试式构造综合式方法情景被“编译”成新的目标模型交互式的和自动的已有研究工作(UCM to LOTOS,UCM to SDL,),小结,小结,情景是合理出现的可能事件序列，基于情景的需求获取方法通过识别这些可能事件序列的集合来获取系统需求，其目的是识别可能的事件出现、确定与这些出现相关的假设、判别其中可能的机会和风险、以及事件的出现过程等。目前，对基于情景的方法的研究还不是很成熟，有一些启发式的情景分析策略。情景分析着眼于具体的细节的系统行为，从具体的应用场景出发，用户易于领会和接受，从而给出对软件系统与环境的主要交互活动的客观描述。,小结,UML用例图中主要的建模元素包括：参与者、用例、用力间的关系。用例描述的主要步骤包括：找出系统的外部参与者和外部系统，确定系统边界和范围确定每一个参与者所期望的系统行为把这些系统行为命名为Use Case使用泛化、包含、扩展等关系处理系统行为的公共或变更部分编制每一个Use Case的脚本绘制Use Case图；区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理细化Use Case图，解决Use Case间的重复与冲突问题,有待研究的问题,问题：取样和覆盖率，两者是相关的未来研究：建立种子情景，自动生成变体（变体太多怎么办？）非形式化和形式化的情景折中从情景中提取知识，或者用情景进行需求测试都还不够成熟需要从文本、语音、图象中抽取知识的工具,有待研究的问题,针对UML中的用例图，开发支持用例分析的方法、技术和工具更深层次的情景推理更多的实践和应用,