中科院需求工程 需求工程（第七讲）问题框架方法_.ppt

需 求 工 程,金芝中国科学院数学与系统科学研究院,第七讲：问题框架方法,关注和定位问题建模元素和问题分析基本问题框架类问题框架关注点总结课程实践,关注和定位问题,为什么要关注于问题？,硬件和软件运行是正确的，但它们完成的功能不是所需要的。开发者的失败在于捕获和理解问题上，而不是设计和实现一个解决方案上。通过关注问题，可以识别出关键的困难，准确理解用户的意图。,如何关注于问题?,病人监护问题医院的重症监护室需要一个病人监护系统。每个病人都要有一个模拟设备来监护，这些设备用来测量诸如脉搏、体温、血压、以及皮肤阻抗等参数。这个系统按（对每个病人特定的）一定周期来读取这些参数，并存储到一个数据库中。医生需指明每个病人各个参数的安全范围。如果某参数的值超出了该病人的安全范围，或者模拟设备失效，则要通知护士工作站。,如何关注于问题?,关注于问题意味着考虑如下问题？所有的病人都要被监护，还是其中的一部分需要被监护？是对不同的病人有不同的参数，还是所有的病人有相同的参数？是医生还是其他什么人指明参数读取周期以及范围？模拟设备在什么情况下可能失效？这些失效能被检测到和诊断出来吗？在病人被监护过程中，病人的监护需求会发生变化吗？,如何关注于问题?,区别欲关注解决方案：应该用什么SQL语句来写数据库？监护过程应该如何调度，以便每个病人都按所需要的频度得到监护？系统应该有哪些对象类？病人列表应保留在Java向量中吗？,如何关注于问题？,图书馆管理问题需要一个系统来管理一个外借图书馆。借书的必须是会员，但在馆内阅览不需要。图书可以预借并从有联系的图书馆那里获得。过期要交罚款。需要各种管理报告。,如何关注于问题？,关注于问题意味着要考虑如下问题：是所有馆藏书都可以外借，还是有一部分只能在馆内阅读？借书期限可延长吗？如果可以，延长的期限是多少？会员可以预留书吗？如果可以，预留多长时间？非会员可以预留书吗？会员要交费吗？会员持续多长时间？允许从有三卷的书中借走其中的一卷吗？,计算机与外部世界,计算机及其上的软件,计算机以外的现实世界,这里是解决方案,这里是问题,现实世界和计算机之间的连接,初始问题关注点（结构化分析）,初始问题关注点（用例）,借书,还书,续借,会员,建模元素和问题分析,领域（标识上下文）,机器领域：我们所要构建的设计领域：设计出来作为信息的物理表示的给定领域：物理领域，其特性是不能改变的,现象（共享现象）,两个领域之间的接口所连接的两个领域共同参与和共享现象的种类：事件：比如，机器和护士工作站共享“监护报警通知”事件状态：比如，机器和模拟设备共享病人皮肤阻抗的状态取值：比如，机器和模拟设备共享要监测的病人的相关数据取值,上下文图：问题在何处,领域机器领域外部环境给定领域设计领域,接口（共享现象）事件状态取值,领域,领域,共享现象,上下文图（病人监护问题）,问题分析,需求（需求现象）客户希望在问题领域中为真的事情问题领域中将成立的关系问题领域将展现的行为希求式的陈述,领域特性每个问题领域中要关注的特性关于领域的客观事实陈述式的描述机器需求机器与问题领域接口上的期望行为,上下文图显示了机器将处于的外部世界（问题领域）的各个部分，但没有显示要解决的问题,领域特性是客户需求和机器需求之间的桥梁,需求引用和需求约束,需求引用和需求约束都是关于问题领域的所以它们都只连接到问题领域需求引用该需求涉及到所连接领域的特定现象需求约束该需求不仅涉及到所连接领域的特定现象，而且还规定了这些现象之间的希望满足的关系，和/或所连接领域的行为,问题图：问题是什么,在上下文图的基础上，进一步显示：现象的进一步细化需求需求引用和/或需求约束,需求陈述,引用的现象,约束的现象,控制现象的领域！具体现象的集合,问题图（病人监护问题）,问题和子问题,分解：控制问题复杂性的关键，常用自顶向下的功能分解用例分解如何判定好的分解？如何判定分解后的不分解前的要容易解决？如何保证分解后的部分正好可以并起来解决原有问题？,问题结构化,子问题是完整的，有自己的问题图，自己的机器，自己的问题领域，自己的需求子问题之间是并行结构，而不是层次结构子问题之间的交互具有并发性，是带有共享变量的多个问题领域机器的并发执行引起的,识别出问题中的子问题,是投影?,还是划分?,家庭供暖控制,一个家庭供暖系统使用热水散热器，每个房间有一个温度感应器，一个温度控制按钮，一个红外线房间占用感应器，一个或多个散热器，以及一个开关计算机控制的散热器阀门。水由一个燃油炉加热，让流过阀门的油吹进燃烧区并点燃，燃油炉有一个火焰感应器，一个燃料流感应器，一个喷射马达速度感应器，和一个水温感应器。一个水泵使水在这个系统中循环。有一个控制面板，通过它可以命令控制器打开还是关上取暖炉；这个面板上还提供一个显示，指明系统的状态和任何的故障。计算机必须控制系统的行为，来使房间的温度保持在控制按钮所设置的温度。从经济方面考虑，没有人住的房间应该比按钮设置的温度低5度，系统可以使用来自房间占用感应器的信息来判断房间的使用情况。,基本问题框架类,基本问题类和问题框架,问题类：软件开发问题可能完全不同但可能有相同或者相似的子问题问题框架：可重复出现的问题模式可根据上下文以及领域特征、接口特征和需求特征来定义以现象的分类为基础划分基本问题类的意义：不同的问题类有不同的需求分析关注点,领域特征,因果领域（causal domain）：在它与外界共享的因果现象之间存在可预测的因果关系。顺从的领域（可叫牌领域）（biddable domain）：通常由人组成，其重要特征是它是物理的，但却没有明确的可预测的内部因果性。词法领域（lexicon domain）：是数据的物理表示，即符号现象。,现象的表示和建模,个体：可以命名并区别于其它个体事件。某个特定时间点上发生或出现的个体，时间点是不可分并且瞬时的：事件没有中间结构，它的发生也不化时间。实体。是一直存在的个体，它可以在不同时间点有不同的特性和状态。一些实体可以启动事件；一些实体的状态可能会自发地变化；一些实体可能是被动的由其它实体改变。值。一个无形的实体，它存在于时间和空间之外，是不会改变的。,现象的表示,关系：一组个体间的关联 状态。实体和值之间的一个关系；它可以随时间而变化。真值。不能随时间发生变化的个体间的关系。角色。一个事件和用一种特殊的方式参与这个事件的个体之间的关系。,现象的类型,因果现象：包括事件、或是角色、或是状态关系实体。它们是直接由一些领域引起的或控制的，并且它们能够反过来引发其它现象。符号现象：包括值、真值以及只与值相关的状态。它们被用来符号化其它现象及其它们之间的关系。,需求式行为框架,存在物理世界的某个部分，它的行为要被控制，以使得它满足确定的条件。问题是要构建一个机器，这个机器将施加所需要的控制。,需求式行为框架例,命令式行为框架,存在物理世界的某个部分，其行为要按照一个操作者发出的命令来控制。问题是构建一个机器，它将接受操作者的命令并相应地施加控制。,命令式行为框架例,水闸门控制一个小水库有一个升降水闸，需要一个计算机系统来控制这个水闸。每三个小时有十分钟这个水闸要处于全开的位置，其余时间让它处于全关的位置。这个水闸用一个垂直转轮来打开和关上，这个转轮由一个小马达来驱动，它可以用顺时针、逆时针、开、关四种脉冲来控制，水闸的顶端和底端各有一个感应器；水闸处于顶端为全开，处于底端为全关。与计算机的连接由四根用于控制马达的脉冲线和两根连接感应器的状态线组成。,信息显示框架,存在物理世界的某个部分，连续地需要关于它的状态和行为的确定信息。问题是构建一个机器，这个机器将从物理世界中获得这些信息，并按所要求的格式呈现在所要求的地方。,信息显示框架例,里程表显示需要一个芯片计算机来控制汽车中的速度计和里程计。它们的显示形式如下图所示：,36.5km/h,50436.9km,车的后轮在旋转时产生脉冲，计算机能够检测到这些脉冲，并用它们来确定在仪表盘计数器上显示出来的当前速度和总行驶公里数。这个计数器的基本寄存器由计算机和显示器共享。,简单工件框架,需要一个工具，让用户创建并编辑确定种类的计算机可处理的正文或图形对象或简单结构，以便它们以后能被拷贝、打印、分析或按其它方式使用。问题是构建一个机器来充当这个工具。,简单工件框架例,晚会计划编辑器Lucy和John需要一个系统来保存他们组织的许多次晚会以及他们邀请来参加晚会的许多客人的情况，他们想要一个简单编辑器来维护这些称之为晚会计划的信息。本质上说，这个晚会计划只是一个晚会列表，一个客人的表，以及一个关于每场晚会都邀请了哪些客人的注释。这个编辑器将用非常古老的DOS或Unix风格来接收命令行文本输入。,变换框架,存在一些计算机可读的输入文件，必须按照确定的规则将它转换成确定格式的输出文件。问题是构建一个机器，它将接收输入并产生所需要的输出。,变换框架例,邮件文件分析Fred决定要写一个分析邮件某些模式的程序。他感兴趣的是每个星期收到和发送的邮件的平均数量，平均和最大的邮件的长度，等之类的事情。他想要如下样子的报表：NameDays#in Max.LthAvg.Lth#OutMax.LthAvg.LthAlbert12419 52136602717219412123Anna9231 13249173637347632918.,基本问题框架变体,描述变体：引入描述领域来描述某部分需求或某方面需求，或者描述可能出现在问题上下文中的某个其它领域。在任何基本框架问题中都可以引入描述领域。比如，在需求式行为框架中引入的描述领域，可以用于显式地表示出受控制的领域的需求式行为，如果需求式行为发生变化，可以更换这个描述领域，控制领域则每词根据描述领域中给出的行为描述来施加控制。比如，在变换问题中引入描述领域，可以用于描述输入领域中的字符和符号之间的关系，变换机器领域则可以根据该描述领域的符号定义对输入领域实施变换。比如，在匹配基本信息框架的问题中，信息机器选择要被显示的信息，选择标准在需求中给出，并建立到机器领域中。引入描述变体后就改变了一种方式，可以将选择标准编码到一个描述领域中，这样这个信息问题就具有与行为问题和变换问题同样的灵活性。,基本问题框架变体,操作者变体：从原理上说，命令式行为框架实际上就是一种操作者变体，它在基本需求式行为框架中引入操作者，要求控制机器保证受控制的领域按照操作者的指令来行动。在基本信息显示框架中也可以引入操作者，构成命令式信息显示框架，这种信息显示框架不象基本信息显示框架那样，在需求中就固定了要显示的信息，而是允许操作者选择要显示的信息，可以将这种信息问题看成是机器回答操作者询问的问题。在这种命令式信息显示问题中，最重要的关注点是确定机器必须能够回答的可能的询问集合。可能的询问集合受到如下三个方面的限制：现实世界和机器的接口上直接存在的共享现象；可以从领域特性中导出的推理结果（可能带有一个显式的模型）；询问的命令语法可以表达的含义。,基本问题框架变体,连接变体：基本的问题框架假设机器领域与所受控制的问题领域直接关联，现实世界问题很多情况下，这样的关联是通过其它的一个领域完成的，如果这个作为连接领域的领域是可靠的，则没有问题，如果这个连接领域不可靠，或者可能带来一些不确定因素的话，就需要专门研究这些连接领域，因而产生基本问题框架的连接变体。在这种情况下，机器并不是直接和问题领域连接，而是显式地通过一个连接领域关联到问题领域，这个问题领域成为机器的远程问题领域。加入了这样的连接领域的问题的分析，除了需要分析问题领域的特性外，还需要分析连接领域的特性，更要分析连接领域是如何影响问题领域，这些影响将反映在其与机器的共享现象上。,基本问题框架变体,控制变体：任何时候都有三个控制方面：事件类型的控制（发生哪类事件？）；事件出现的控制（什么时候发生？）；事件角色的控制（需要哪些个体参与？）。当共享事件的控制发生了改变时，则出现了相应的控制变体。举例：行为和信息问题一般没有控制变体，因为在这两个问题中共享事件的控制是严格规定的，否则它们就已经变成为其它的基本问题。变换问题和工件问题则有可能存在控制变体，比如，被控制的变换问题，其变换过程由输入/输出领域控制。,问题框架关注点,需求式行为框架关注点,关注点一：需求,forevershow only Stop(1)and Stop(2)for 50 seconds;show only Stop(1)and Go(2)for 120 seconds;show only Stop(1)and Stop(2)for 50 seconds;show only Go(1)and Stop(2)for 120 seconds;,关注点二：领域特性,?,RPulse,RPulse,GPulse,GPulse,GPulse,关注点三：规格说明,RPulse(1);RPulse(2);/设置Stop(1),Stop(2)forever wait 50 seconds;RPulse(2);GPulse(2);/改变Stop(2)到Go(2)wait 120 seconds;GPulse(2);RPulse(2);/改变Go(2)到Stop(2)wait 50 seconds;RPulse(1);GPulse(1);/改变Stop(1)到Go(1)wait 120 seconds;GPulse(1);RPulse(1);/改变Go(1)到Stop(1),命令式行为框架关注点,关注点一：需求,合理的命令,Raise,Stop,Stop,Lower,Raise,Stop,Stop,Lower,Stop,Stop,Stop,关注点一：需求,可行的命令（需要服从）无论对什么命令，门在运行到顶端和底端时必须停下来：如果在Rising为真时Open变为真，则Rising必须立即变成假，而Falling必须保持为假。如果在Falling为真时Shut变为真，则Falling必须立即变成假，而Rising必须保持为假。与1中的需求不同，水闸门必须在响应可行的SRaise，SLower和SStop命令时才改变它的Rising和Falling状态：如果在Rising和Falling都不为真时出现SRaise命令，并且Open不为真，则Rising必须立即变为真。如果在Rising和Falling都不为真时出现SLower命令，并且Shut不为真，则Falling必须立即变为真。如果在Rising为真时出现SStop命令，则Rising必须立即变为假，而且Falling必须保持为假。如果在Falling为真时出现SStop命令，则Falling必须立即变为假，而且Rising必须保持为假。除了1和2.1到2.4中的需求之外，Rising和Falling状态必须保持不变。,关注点二：领域特性（现象）,MOn指电流作用在马达上；DC1指旋转的方向被设成顺时针；如果DC1为假，则旋转的方向被设成逆时针；Posn(p)指水闸门处于离它垂直运行的底端p英寸的位置上；Top指顶端的感应器被激活；Bottom指底端的感应器被激活；Open指水闸门是开的，水能够流过；Shut指水闸门是关闭的，水不能流过。,关注点二：领域特性,On,Off,Clockw,Anti,On,Off,Anti,Clockw,关注点三：规格说明,检测到由水闸门操作者发出的Raise，Lower和Stop命令；拒绝那些不合理的命令；忽略那些在水闸门&马达的当前状态下，不可行的和不能服从的合理命令；按照被服从的命令需求，实现所需求的Rising和Falling状态，作为对合理可行命令的响应。,信息显示框架关注点,1,2,3,4,5,6,关注点一：领域特性,所有的车辆行为自行车、小汽车和商务车等通过时能够发生的每一件事情，包括紧跟着其后面行驶、超车、故障、以及所有像这种的事情；所有的感应器行为机器能够检测到的各种可能的感应器状态模式；两者之间的完整的关系。,简单工件框架关注点,关注点一：领域描述,晚会规划操作（增加/减少客人，增加/减少晚会，增加/减少客人晚会关联）晚会规划行为（对应上述操作的各种状态变化）,客人,晚会,关注点二：需求,不正确的操作命令语法根据命令上下文的命令可行性依据命令上下文和当前晚会状态的命令效果,关注点三：规格说明,识别和拒绝那些语法上不正确的命令；保持命令上下文并按语法上正确的命令序列来维护；根据领域特征，定义提供保证所需要的效果的晚会规划操作。,变换框架关注点,关注点一：输入领域特性,关注点一：输出领域特性,关注点二：需求,ReportBody对每个邮件文件有一行CorrespLine：CorrespLine必须按名字的降序排列；CorrespLine中的八个域的值从所关联的邮件消息中导出，像这个样子：Name是来自邮件文件DirectoryEntry的MFName；Days是邮件文件中DateLines中最早和最迟日期之间的差加一；#In邮件文件中收到消息的记数（这些是ToLine为To:的消息）；IMax是收到的最长的消息的长度（消息的长度为MsgBody中的字符个数，包括CRLF字符）；IAvg是收到的消息的平均长度；#Out为不是所收到的消息的记数；OMax为不是收到的消息的最长长度；OAvg为不是收到的消息的平均长度。,几个需要关注的问题,溢出关注点：溢出关注点指，在一个领域的下一事件出现之前，是否能对每个外部控制的事件做出反应。两个领域之间出现事件或状态变化上的共享当两个领域接口上存在速度上的不匹配时溢出关注点就会产生。例如：在邮件文件分析问题中，John和Lucy的输入命令可能比晚会编辑器能够处理的速度要快，则在John和Lucy领域与晚会编辑器之间存在溢出关注点。在小区交通监视问题中，监视计算机可能会以快于行式打印机可能打印的速度来产生信息输出事件，则在监视计算机与行式打印机之间存在溢出关注点。解决策略：延迟、忽略、缓冲,几个需要关注的问题,初始化关注点：初始化关注点指，机器领域将在其上运行的问题上下文的初始状态。初始化机器领域初始化物理世界领域，如果物理世界领域是自治的，或者连续变化的，无能为力，只能暂且指定一个状态作为初始状态例如：在行为问题中，通常可以从问题领域被机器领域控制的状态中选择一个作为机器领域要关注的初始状态。在信息显示问题中，却不能这样处理，因为在这里，物理世界中的问题领域是自治的，是完全不受机器控制的。在这种情况下，可能需要给机器领域施加一些控制，将它变得与物理世界问题领域同步。当与机器领域共享现象的领域为设计的领域时，通常可以事先将这个设计领域初始化。,几个需要关注的问题,可靠性关注点：是针对特定的问题领域的，解决可靠性关注点意味着要为保证系统能应对某些失效带来的风险而付出代价，这个可靠性代价是否值，依赖于赔付的规模、失效的可能性、以及这个失效会引起的损坏的严重性。在安全关键系统中，损坏的严重性可能会非常大，使得必须要用更高的代价来保证能应对甚至不太可能发生的失效。在病人监护问题中，即使可以假设模拟设备是可靠的，也仍然必须诊断并报告它们的失效，因为失效会使病人的生命处于危险之中。在非安全关键系统中，如果能够化不多的代价就能保证安全的话，可能也愿意采取措施以便能对抗会引起小损坏的远程风险，但如果代价太高就算了。解决策略：解决可靠性关注点的一种方式是进行问题分解，首先需要定义一个更精确的问题领域描述，其中包含了所有可能的失效，然后引入失效检测子问题去检测这个可能失效的问题领域。,几个需要关注的问题,身份关注点：身份关注点关于识别属于同一个问题领域的不同个体，这个问题领域的多个实例具有独立存在性。当机器领域与一个多重问题领域的个体之间存在共享现象时，就出现了身份关注点。一个多重问题领域由一类实体的多个实例组成，这些实例没有被连接到任何识别它们的结构上，并且也不能识别它们自己。在机器领域需要将多重领域中的一个个体区别于另一个个体的时候，身份关注点才出现。解决策略：解决身份关注点的焦点是共享现象的接口，机器可以一次只被连接到一个或同时几个个体。在任何一种情况下，对所共享的事件或状态，这个关注点都是关于机器领域与哪个个体共享。当机器领域可以一次只连接到一个正确的个体上的时候，身份关注点就消失了。有时需要引入一个设计领域来保证正确地识别个体身份。,几个需要关注的问题,完整性关注点：完整性关注点是关于保证问题需求、问题领域、和机器描述是完整的。完整性关注点关于要保证软件将做客户需要的任何事情。明显地，这个关注点与需求抽取的目标相关,总结,问题框架方法是一种面向问题域的方法，它直接分析问题并对问题进行结构化，它识别问题中将与机器领域发生直接/远程交互（共享现象）的问题领域，并以此作为问题的边界（上下文图），问题框架方法中的需求特指在期望的引入机器领域后的问题领域要满足的约束（问题图），它采用投影原则划分问题，问题和子问题具有同样的维度和结构。问题框架方法定义一组基本问题框架（问题框架图），每个基本问题框架具有自己特有的问题关注点，这些关注点为对符合这些基本问题框架的问题进行分析提供了依据。为了应对物理世界问题的复杂性，问题框架方法还提供了一些问题框架的变体技术，以扩大问题框架所能适应的问题种类范围。值得注意的是，为了提高问题框架方法的可用性，除了本书给出的变体形式之外，还需要引入更多的问题框架和问题框架变体，这是一个值得并确实必须进一步深入的研究领域。,总结,现实生活中的大多数实际问题可能都找不到一个现成可用的问题框架，必须通过显式地将它们分解为简单的子问题来处理，这些实际问题是一些以复杂的方式相互交互的简单子问题的组合，这些交互引出了组合关注点。在面向服务的软件逐步受到人们关注的今天，组合关注点的引入具有更深层的含义，即在需求阶段研究如何用“小”的服务（子问题）组合成“大”的服务（问题），并为这个组合建模并进行模型的分析。问题框架方法关于问题领域建模的思想，以及以共享现象作为问题分析的基础的理念，为组合关注点的解决提供一个思路。,课程设计,试图寻找2个或者多个参与者各个参与者的策略上的关注点(目的,能力等)建立参与者之间的策略依赖模型建立策略理性模型根据策略理性模型探索可能的改变,课程设计参考应用领域,选择一个你最近知道的或者考虑过的领域电子商务远程教育电子政务出版电子图书、电子杂志图书馆管理在线会议管理,课程实践形式,需求信息抽取阶段：自由分组（4-6人一组）任务：确定软件开发案例问题范围确定需求相关者（各成员扮演不同的角色）获取需求信息结果：小组成员组成和角色分配软件开发问题的界定和明确的陈述初步的需求描述，可用自然语言语句表示要求：捕获尽可能多的需求信息,课程实践形式,建模和分析阶段：个人独立完成任务：选择一种或结合多种学过的需求工程方法、按照选定方法要求的过程步骤以及内容形式，根据上述初步需求描述开发需求模型、结合需求模型进行适当的分析结果：完整的需求说明要求：模型表示形式要符合规范，建模原理阐述要清楚，建模和分析步骤要明确,