需求建模方法与技术.ppt

1,需求工程 Ch05 需求建模方法与技术,Mail:,主讲教师：赵 辉,2,第5章 需求建模方法与技术,需求建模主要是根据待开发软件系统的需求，利用某种建模方法建立该系统的逻辑模型（也称需求模型或分析模型），以帮助软件开发人员检测软件需求的一致性、完全性、二义性和错误等。软件建模方法特点：1.提供描述手段；2.提供基本步骤。,3,第5章 需求建模方法与技术,5.1 什么是模型5.2 软件工程中的模型5.3 结构化的需求建模方法5.4 面向对象的需求建模方法5.5 基于图形的需求建模技术,4,5.1 什么是模型,模型的定义由某些人根据其目的而对事物进行的抽象描述。根据实物、设计图或设想，按比例生成或其他特征制成的同实物相似的物体。当一个数学结构作为某个形式语言（即包括常符号、函数 符号、谓词符号的集合）的解释时，称为模型。为了理解事物而对事物作出的一种抽象，是对事物的一种无二义性的书面描述。,5,5.1 什么是模型,模型的分类 描述性模型规约性模型探测性模型,需求模型既是描述性模型（描述问题域），又是规约性模型（软件的需求规格说明）。,6,5.2 软件工程中的模型,软件工程中模型的概念 对客观世界的问题领域进行抽象并用某描述方法给予表示的结果称为模型。注意问题：问题域中有什么对象？应该选择什么样的关系或动作？如何用适当的模型给予表示？,7,5.2 软件工程中的模型,软件工程中模型的分类开发过程模型信息流模型 设计模型 交互作用模型 状态迁移模型 用于构造细节的原理模型 过程成熟度模型 其它模型（可靠性模型，成本估算模型）,8,5.3 结构化的需求建模方法,SA方法的特点表达问题时尽可能使用图形符号的方式，这样即使非计算机专业人员也易于理解；设计数据流图时只考虑系统必须完成的基本功能，完全不需要考虑如何具体地实现这些功能。,9,5.3.1 SA方法的基本思想,基本思想按照由抽象到具体、逐层分解的方法，确定软件系统内部的数据流、变换（或加工）的关系，并用数据流图给予表示。复杂系统分解示例,10,5.3.2 SA方法的描述手段,组成一套分层的数据流图 一本词典 其它补充材料 数据流图（DFD：Data Flow Diagram）描述系统内部处理流程、用于表达软件系统需求模型的一种图形工具，亦即是描述系统中数据流程的图形工具。,11,5.3.2 SA方法的描述手段,DFD的简例,源点,数据流,数据加工,文件,终点,12,5.3.2 SA方法的描述手段,数据流 数据流是由一组数据项组成的数据，通常用带用带标识的有向孤给予表示。数据流可以加工之间，源点与加工之间，终点与加工之间，加工与文件之间流动。在数据流的命名中，不能使用缺乏具体含义的词如“数据”、“信息”等当作为数据流名。不能把控制流作为数据流。,13,5.3.2 SA方法的描述手段,加工（变换）对数据进行的操作或变换就称为加工。加工的命名方法最高层的加工可以是软件系统的名字；加工的名字最好由一个谓语动词加上一个宾语组成；不能使用空洞或含糊的动词作为加工名；当遇到不能合适命名的加工时，可以考虑将加工分解。,14,5.3.2 SA方法的描述手段,文件文件是存放数据的逻辑单位，且通常用图形符号“”，“”和“”分别表示加工要写文件，读文件和读写文件。另外，在这个图形符号中还要给出文件名。源点和终点源点和终点用于表示数据的来源和最终去向，且通常用图形方框给予表示。,15,5.3.2 SA方法的描述手段,例：某培训中心管理信息系统,16,5.3.2 SA方法的描述手段,分层的DFD对于大型而又复杂的软件系统，如果用一张DFD说出所有的数据流和加工，整个图就会变得相当复杂和难以理解，而且一张纸也难以写下这样的图。为了控制复杂性，通常可采用分层的方法。分层DFD的组成 顶层、底层和中间层。,17,5.3.2 SA方法的描述手段,画完整的分层的DFD需注意的几个问题 在画DFD时应区别于流程图 DFD的完整性问题 DFD的一致性问题（示例）在分层DFD中文件的表示 分解层次的深度（准则）,18,5.3.2 SA方法的描述手段,一致性问题示例,19,5.3.2 SA方法的描述手段,分解层次深度的应验性准则某个加工的分解最好不超过78层，尽量减少分解层次；分解应根据问题的逻辑特性进行，不能硬性分解；每个加工被分解为子加工后，子图中的子加工数不要太多，通常为710个；上层可分解快些，下层应该慢些，因为上层比较抽象，易于理解；,20,5.3.2 SA方法的描述手段,分解要均匀，即在一张DFD中，有些已是基本加工，另外一些还要被分解为多层；分解到什么程度才能到达底层DFD呢？一般来说应满足两个条件：一个是加工能用几句或十几句话就可清楚地描述其含义。另一个是一个加工基本上只有一个输入流和一个输出流。,21,5.3.2 SA方法的描述手段,画分层的DFD的步骤 先确定软件系统的输入/出数据流、源点和终点；将基本系统模型加上源点和终点构成顶层DFD；画出各层的DFD。（准则）,22,5.3.2 SA方法的描述手段,画每张DFD时，应遵循的准则 将所有软件的输入/出数据流用一连串加工连接起来；应集中精力找出数据流；标识找到的数据流，分析该数据流的组成成分及来去方向，并将其与某加工连接，标识加工；当加工需要用到的共享和暂存数据时，设置文件及其标识；,23,5.3.2 SA方法的描述手段,画每张DFD时，应遵循的准则 分析加工的内部，如果加工还比较抽象或其内部还有数据流，则需将该加工进一步分解，直至到达底层图；为所有的数据流命名；为所有加工命名编号。,24,5.3.2 SA方法的描述手段,在画DFD时还应注意的情况画图时只考虑如何描述实际情况，不要急于考虑系统应如何启动，如何工作，如何结束等与时间序列相关的问题；画图时可暂不考虑一些例外情况如出错处理等；画图的过程是一个重复的过程，一次性成功可能性较小，需要不断地修改和完善。,25,5.3.2 SA方法的描述手段,示例 某医院拟开发一个分布式患者监护系统（PMS:Patients Monitoring System）。PMS将用于监视病房中每个患者的重要生理信号（如体温、血压、脉博信号等），并能定时更新和管理患者的病历。此外，当患者的生理信号超过医生规定的安全范围时，系统能立即通知护理人员，并且护理人员在需要时可随时通过系统产生某患者有关报告。,26,5.3.2 SA方法的描述手段,PMS的主要功能为：通过一个病床监视器实现本地监测，以获得患者的生理信号。在护士办公室实现中央监测 更新和管理患者病历 产生患者情况的报告以及报警信息,27,5.3.2 SA方法的描述手段,第0层数据流图,28,5.3.2 SA方法的描述手段,第1层数据流图,29,5.3.2 SA方法的描述手段,第2层数据流图,30,5.3.2 SA方法的描述手段,数据字典数据词典是由DFD中所有元素的“严格定义”组成。其作用就是DFD中出现的每个元素提供详细的说明，即DFD中出现的每个数据流名、文件名和加工名都在数据词典中应有一个条目以定义相应的含义。,31,5.3.2 SA方法的描述手段,数据词典中的条目类型数据流条目：用于定义数据流,主要说明由哪些数据项组成数据流，采用简单的形式符号方式定义。对于复杂的数据流，可采用向顶向下逐步细化的方式定义数据项。例：订票单顾客信息+订票日期+出发日期+航班号+顾客信息 姓名+性别+身份证号+联系电话,32,5.3.2 SA方法的描述手段,当数据项由多个更小的数据元素组成时，可利用集合符号“”给予说明。如：选修课程 课程表+教师+教材 课程表 课程名+星期几+上课时间+教室 当某些数据项是几个不同的数据流的公用数据项时，可将它们列为专门的数据项条目。如：教室101|102|航班号Mu712|Mu814|,数据词典中的条目类型数据流条目：用于定义数据流,33,5.3.2 SA方法的描述手段,当所有出现在DFD中的数据流都给予定义后，最后的工作就是对出现在数据流中的数据项进行汇总，然后以表格的形式汇录每一数据项。如：,数据词典中的条目类型数据流条目：用于定义数据流,34,5.3.2 SA方法的描述手段,文件条目：用于定义文件 除说明组成文件的所有数据项（与数据流的说明相同）外，还可说明文件的组成方式。如：航班表文件 航班号+出发地+目的地+时间 组成方式 按航班号大小排列,35,5.3.2 SA方法的描述手段,加工条目：用于说明加工 加工条目主要描述加工的处理逻辑或“做什么”。加工条目并不描述具体的处理过程，但可以按处理的顺序描述加工应完成的一些功能，而且描述加工的手段通常使用自然语言，或者结构化的人工语言，或者使用判定表或判定树的形式。,36,5.3.2 SA方法的描述手段,实例：某培训中心管理信息系统中的“处理报名”加工描述如下：根据报名要求查询收费标准文件，确定相应费用。学生注册 根据选修课程登录课程统计文件 产生注册单等 由所有的数据条目、文件条目和加工条目就构成一本数据词典。,37,练 习,某学校计算机教材购销系统有以下功能：学生买书，首先填写购书单，系统根据各班学生用书表以及售书登记表审查有效性，若有效，计算机根据教材存量表进一步判断书库是否有书，若有书，计算机把领书单返回给学生，学生凭领书单到书库领书。对脱销的教材，系统用缺书单的形式通知书库，新书购进库后，也由书库将进书通知返回给系统。请就以上系统功能画出分层的DFD图,并建立主要的文件条目的数据字典.,38,5.3.3 实例说明,某学校拟开发一个运动会管理系统。有关运动会的业务流程如下：（1）确定运动会的举办时间和地点，设置哪些项目，报名时间等（2）确定一些限制规定，如每人最多可参加几个项目，每个项目每队最多可由多少人参加，取前几名，打破单项比赛记录后的处理等。,39,5.3.3 实例说明,（3）由各参加队提供报名单后，需给每个运动员编号，并统计每个项目的参加人数及名单，最后根据每个项目的参加人数等具体情况排出比赛日程。（4）在运动会期间不断接受各项目的比赛成绩，及时公布单项名次，累计团体总分。（5）比赛结束后，公布最终的团体名次。,40,5.3.3 实例说明,第0层数据流图,41,5.3.3 实例说明,第1层数据流图,42,5.3.3 实例说明,第2层数据流图,43,5.3.3 实例说明,第2层数据流图,44,5.3.3 实例说明,数据字典说明数据流条目,45,5.3.3 实例说明,汇总后的数据项,46,5.3.3 实例说明,文件条目,47,5.3.3 实例说明,加工条目,48,5.3.3 实例说明,49,5.3.4 SA方法的分析步骤,为简单起见，我们将现实中已存在的人工系统称为当前系统，把待开发的计算机系统（主要是指软件系统）称为目标系统。步骤理解和分析当前的现实环境，以获得当前系统的具体模型；建立当前系统的逻辑模型；建立目标系统的逻辑模型；进一步完善目标系统的逻辑模型,50,5.4 面向对象的需求建模方法,面向对象的需求建模方法到目前为上已有许多不同的版本，其中具有代表性的是OOD、OMT、OOSE、OOAP和UML等。在这些需求建模方法中，本节将主要介绍基于OMT的需求建模方法，而且重点放在需求建模方面，有关UML的内容将在后面章节给予说明。,51,5.4.1 面向对象方法中的一些基本概念,对象客观世界中存在大量实体。实体可以是物理的，也可以是概念的，所谓对象就是以上的客观实体的抽象，并且是构成概念模型的基本单元。对象是具有相同状态的一组操作组成。对象是封装数据结构及可以施加这些数据构上的操作的封装体。这个封装体，可以有可以唯一标识它的名字，而且向外可提供一组服务。,52,5.4.1 面向对象方法中的一些基本概念,对象图形表示如下：,53,5.4.1 面向对象方法中的一些基本概念,类 类是对具有相同性质和操作的一个或多个对象的描述，并且是一组对象的集合。性质继承性质继承是指能够直接获得已有的性质和特征，而不需要重复定义它们。性质继承主要是由父类与子类的关系引起的，其中子类除了具有自己的属性和内部操作外，还可继承父类的全部属性和内部操作。,54,5.4.1 面向对象方法中的一些基本概念,消息 消息是系统运行过程中对象之间相互传递的、请求服务的信息。通过消息实现对象之间的通信是OOM的重要原则之一。类之间的关系 类之间的泛化关系 这种关系主要是因类之间继承关系而形成的类层次结构。在OOM中用“一般 特殊”或“Is a”这一关系来定义这种结构。,55,5.4.1 面向对象方法中的一些基本概念,泛化关系的表示,56,5.4.1 面向对象方法中的一些基本概念,类之间组成关系 这种关系是因一个对象是另一个对象的组成部分而形成的结构关系。,组成关系的表示,57,5.4.1 面向对象方法中的一些基本概念,对象属性间的静态关系 所谓对象属性间的静态关系是指可以通过对象中的属性形成对象间的一种相关依赖关系。关联与实例连接的关系就像类与对象的关系一样，实例连接可看做是关联的实例。,实例连接的图形表示,58,5.4.1 面向对象方法中的一些基本概念,对象行为间的动态关系 这种动态行为关系主要是由对象间的消息连接而形成的。一个对象可以通过消息向其它对象提出执行动作的要求，动作执行完后的对象通过消息可发送执行的结果等。,59,5.4.2 面向对象的需求分析,根据面向对象的过程模型，面向对象的需求分析从概念上被分为问题分析和应用分析两个方面。,60,5.4.2 面向对象的需求分析,问题分析 问题分析的主要任务是收集并确认用户的需求信息，对实际问题进行功能分析和过程分析，从中抽象出问题中的基本概念、属性和操作，然后用泛化、组成和关联结构描述概念实体间的静态关系。最后，将概念实体标识为问题域中的对象类，以及定义对象类之间的静态结构关系和信息连接关系。最终建立关于对象的分析模型。,61,5.4.2 面向对象的需求分析,应用分析 应用分析的主要任务是动态描述系统中对象的合法状态序列，并用动态模型表达对象的动态行为、对象之间的消息传递和协同工作的动态信息。虽然面向对象的概念是相同的，但由于分析工作的出发点、过程和模型的表达不同，故形成了不同的面向对象的分析方法。如：OMT方法和OOAD方法。,62,5.4.3 OMT方法的图形描述工具,OMT方法中的三种需求模型及其描述工具对象模型类图 动态模型状态转换图和序列图 功能模型数据流图,63,5.4.3 OMT方法的图形描述工具,状态转换图 状态转换图（简称状态图）通过描述系统的状态及引起系统状态转换的事件来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作（如处理数据）。,64,5.4.3 OMT方法的图形描述工具,一个状态图主要由状态、事件和状态变换组成，其中：状态：状态是任何可以被观察到的系统行为模式。事件：事件是在某个特定时刻发生的事情，它能引起系统做动作，并使系统从一个状态转换到另一个状态。状态转换：由某事件引起的两个状态之间的变化称为状态转换。,65,5.4.3 OMT方法的图形描述工具,画状态图的基本步骤：确定初态；确定事件（事件可由动作或输入信息等形成），并根据事件以及某些限制条件确定由当前状态转到下一个状态以形成一个状态转换；重复2的过程，直到最后确定结束状态为止。,66,5.4.3 OMT方法的图形描述工具,状态图示例例1：一个人带着一头狼、一头羊以及一棵青菜，处于河的左岸。有一条小船，每次只能携带人和其余的三者之一。人和他的伴随品都希望渡到河的右岸，而每摆渡一次，人仅能带其中之一。然而，如果人留下狼和羊不论在左岸还是在右岸，狼肯定会吃掉羊。类似地，如果单独留下羊和菜，羊也肯定会吃掉菜。如何才能既渡过河而羊和菜又不被吃掉呢？,67,5.4.3 OMT方法的图形描述工具,68,5.4.3 OMT方法的图形描述工具,例2：电话系统状态图,69,5.4.3 OMT方法的图形描述工具,扩充的状态转换图 扩充后的状态图仍继续沿用原来状态图符号。引入超状态（也称抽象状态）的概念，而超状态又可表示为由多个状态组成的状态图（或称子状态图）基于超状态概念，状态图可表示为层次式的，并且每个超状态可表示一个处理过程。超状态间的关系可用“与”和“或”关系给予表示。,70,5.4.3 OMT方法的图形描述工具,一个上层状态图的事件可同时引起多个并行状态图（处理过程）工作。此外，并行的状态图之间可互相通过事件使对方发生状态转换。多个并行的状态图首先处于各自的初始状态，然后各状态图根据事件各自发生状态转换。这些状态图能通过某一事件同时到达上层状态图中的某一状态；也可以由某一子状态图通过某一事件到达上层状态图中的某一状态，从而强制结束并行执行的状态。每个子状态图都有各自的初始状态，而结束状态的有无可视具体情况设置。,71,5.4.3 OMT方法的图形描述工具,扩充的状态转换图简例,72,5.4.3 OMT方法的图形描述工具,扩充的状态转换图示例,73,5.4.3 OMT方法的图形描述工具,序列图 序列图主要用于表达对象与对象之间可能发生的所有事件，以及按事件发生时间的先后顺序列出所有事件的一种图形工具。,74,5.4.3 OMT方法的图形描述工具,序列图用一条竖直线表示一个对象或类，用一条水平的带箭头的直线表示一个事件，箭头方向是从发送事件的对象指向接受事件的对象。事件按产生的时间从上向下逐一列出。箭头之间的距离并不代表两个事件的时间差，带箭头的直线在垂直方向上的相对位置（从上到下）表示事件发生的先后顺序。,75,5.4.3 OMT方法的图形描述工具,序列图的简例,76,5.4.3 OMT方法的图形描述工具,示例：电话系统序列图,77,5.4.4 基于OMT方法的需求建模步骤,78,5.4.4 基于OMT方法的需求建模步骤,示例：ATM系统需求描述（详见课本P65）,79,5.4.4 基于OMT方法的需求建模步骤,建立对象模型,80,5.4.4 基于OMT方法的需求建模步骤,ATM系统初始类图,81,5.4.4 基于OMT方法的需求建模步骤,带属性标示的ATM系统的对象模型,82,5.4.4 基于OMT方法的需求建模步骤,简化后的对象模型,83,5.4.4 基于OMT方法的需求建模步骤,构建动态模型,84,5.4.4 基于OMT方法的需求建模步骤,编写场景 场景的编写过程实质上也就是一个分析用户对系统交互行为的需求的过程，因此，在编写场景的过程中应与用户充分交流和讨论。编写场景时，应首先编写正常情况的场景，然后再考虑特殊情况，最后，考虑出错情况。,85,5.4.4 基于OMT方法的需求建模步骤,ATM系统的正常情况场景,86,5.4.4 基于OMT方法的需求建模步骤,ATM系统的异常情况场景,87,5.4.4 基于OMT方法的需求建模步骤,设计用户界面 在设计用户界面时，用户界面的细节并不太重要，重要的是在这种界面下的信息交换方式。,ATM初步的用户界面,88,5.4.4 基于OMT方法的需求建模步骤,建立序列图 构造序列图时，首先应认真分析每个场景的内容，从中提取所有外部事件信息及异常事件和出错条件的信息。传递信息的对象的动作也可作为事件。事件形成对象与对象之间的交互行为。确定了每类事件的发送对象和按受对象之后，就可以利用序列图将事件序列以及事件与对象间的关系清晰和形象地表示出来。每个场景对应一张序列图。,89,5.4.4 基于OMT方法的需求建模步骤,ATM系统正常情况场景的序列图,90,5.4.4 基于OMT方法的需求建模步骤,构建动态模型 状态图适用于表示动态模型，其刻画了事件与对象状态之间的关系。依据序列图构造状态图的过程如下：（1）分析序列图；（2）正常事件描述之后，还应考虑边界情况下可能发生的事件；（3）根据一张序列图画出对象或类状态图之后，再把其它与该对象或类相关的场景（如异常情况场景）的序列图加入到已画出的状态图中。,91,5.4.4 基于OMT方法的需求建模步骤,ATM的状态图,92,5.4.4 基于OMT方法的需求建模步骤,总行类的状态图,93,5.4.4 基于OMT方法的需求建模步骤,分行类的状态图,94,5.4.4 基于OMT方法的需求建模步骤,构建功能模型 功能模型主要表达系统内部数据流的传递和处理的过程。数据流图适用于描述系统的功能模型。,95,5.4.4 基于OMT方法的需求建模步骤,定义类和对象中的操作定义类和对象中操作的原则如下：（1）基本的属性操作；（2）事件的处理操作；（3）完成数据流图中处理框对应的操作；（4）利用继承机制优化服务集合，减少冗余服务。,96,5.5 基于图形的需求建模技术,优点图形具有直观性、简单性以及可理解性等优点；图形能自然地表达客观世界；在实体之间，满足传递关系的情况有很多，这可以理解成图中路径探索，并可以研究路径探索的有效算法。,97,5.5 基于图形的需求建模技术,存在的问题图形的语义往往有时是含糊的；在图中不能表示数据定义；图形中表示符号的种类有限。,98,5.5.1 UML概述,UML（Unified Modeling Language）是综合面向对象分析/设计方法中使用的各种图形描述技术，并试图给出这些图形描述的语法和语义的语言。UML以各种图形描述为主分别表示面向对象方法中的不同方面的模型。这些图形可分为表示对象静态结构和动态结构两大类：静态结构类：用例图、类图、Component图等；动态结构类：状态图、活动图、序列图、协作图和配置图等。,99,5.5.2 活动图,UML的活动图是用于表示系统的控制流的，且是状态图的特殊形式。构成活动图的主要元素:,100,5.5.2 活动图,示例：自动贩卖机的活动图,101,5.5.2 活动图,在流程图中，动作的主体通常是由计算机所决定的，故动作的主体是谁无关紧要。但在面向对象的框架中使用活动图就使得各种各样的对象成为活动的主体。为了明确地表示出活动的主体，也可使用标识主体的描述方法,102,5.5.2 活动图,当把活动图视为图形时，其路径可被解释为执行路径。而且根据不同的图示，分支可被解释为“or”关系（选择分支），即可选择任一路径执行；也可被解释为被“and”关系（并行分支），即所有的路径同时执行。此外，活动图还可表示为层次结构，使得活动图可象数据流图一样进行分解。,103,5.5.3 协作图,协作图用于表示对象间消息往来。虽然序列图在某种定义上也能表示对象的协作动作，但能明确描述对象间的协作关系的还是协作图。协作图便于描述对象间有什么样的协作关系，其不需要像一个序列图只能对应于一个场景一样，可以将多个场景中的协作关系一次性地全部描述出来。,104,5.5.3 协作图,示例：自动贩卖机的协作图,105,5.5.4 实体关联图,实体关联图亦称ER图（Entity-relationship diagram）或称实体联系图，主要用于描述系统的数据关系。组成 实体、实体间的关联和属性。实体间的关联一对一关联、一对多关联和多对多关联。,106,5.5.4 实体关联图,示例：某校学生管理系统的ER图,107,5.6面向问题域的分析（PDOA）,PDOA是一项很新的技术；与SA和OOA相比，PDOA更多地强调描述，而较少去强调建模。它直接靠文本来完成。描述大致划分为:(1)关注于问题域（2）关注于解系统的待求行为。同时建议有两个单独的文档：（1）含有对问题域相关部分描述以及一个需在该域中求解的问题列表（即需求）。（2）包含的是对解系统的待求行为的描述以解决需求（即规格说明书）问题框架优点：作为一个全新的模型被引入；有助于把需求从问题域的内在性质中区分出来；还有助于建立问题域的类型。,108,整个方法过程的基本步骤可以定义为：(1)搜集基本的信息并开发问题框架，以建立问题域的类型。(2)在问题框架类型的指导下，进一步搜集详细的信息并给出一个问题域相关特性的描述。(3)基于以上两点，收集并用文档说明新系统的需求。,5.6面向问题域的分析（PDOA）,109,问题框架,定义：是将问题域建模成一系统相线关联的子域，而一个子域（也叫域）可以是那些可能算是精选出来的问题任一部分。问题框架与上下文图的区别：建模对象不同，上下文图建模对象是解系统上下文；问题框架建模对象是问题上下文。目的不同，问题框架的目标是大量地捕获更多的有关问题域的信息；上下文图展示的只是问题域的元素，这些元素对新的解系统是外部可见的，并且直接与之相连接。这些元素又称作端子。问题框架应用于软件开发问题只是最近才有的事；应用尚处于早期阶段，且仍在迅速发展之中。,110,一、问题框架的类型,PDOA与其它分析方法的最生要的区别之一在于对问题域的分类方式。了解问题的类型有益于正确指导分析以及规格说明。Jackson提出了问题的分类：工件系统控制系统信息系统转换系统连接系统,111,以上这些问题类型的每一种随即拥有一个典型问题框架，但在对这些不同的问题框架做详细分析之前，以Petri网图表处理工具为例。上下文图图4。28展示了一个用户的内容。图4.29相应问题框架-不仅满足了Petri网文档的要求，而且使用规则一目了然，这些规则用来定义所执行的绘制Petri网操作的结果。,112,下面对有关表示法做解释：矩形框：感兴趣的领域（问题域中的元素）双矩形（或带双边条的矩形）：解系统 椭圆：用于显示和命名域间的重要逻辑关系 连接域的实线：指出这些域之间存在某种关系。虚线：代表一个需求的引用。,113,大的实心点：用于指出一个域包含在另一个域当中。该表示法的优点：一旦识别了问题类型，我们即可根据指示对问题的相关方面调查和记录。表4.3和表4.4指出了有关工件问题的需求文档和规格说明书。,114,二、问题域、需求及语态,与其他方法不同，PDOA清楚地区分问题域的内在特性以及在问题域中要求产生的变更。Jackson将其刻画为语态的区别，关于问题域内在质量的声明是在指示语态下做出的。例如：电梯传感器 赛艇实际用时。另一方面，新系统能够控制的，即要求产生的结果。例如：电梯不应当在快速模式时停止。只有当电梯停于某楼层时才能改变方向。,115,三、子域交互,正如在上文提到的，连接各子域的线段代表了它们之间的关系或交互的作用；而这些子域交互是以共享或引用对象的形式出现。,116,四、子域类型和问题框架调整,1、子域类型：动态域，静态域动态域又可分为：能够修改自身的域（自修改）-又称为反应性的。根据在修改时是否要求有外部激励的参与还可以进一步进行划分。例如：ADT。仅由外部机构修改的域，例如：文件。,117,其他一些域可能会自主地改变，对于这些域必须考虑如何使得它们的行为可控或可以预知。分为：可编程的：如果完成全可预知的，那么域就称为可编程的。顺从的：如果一个域的行为是部分可预知的，例如：人类用户。自治的：一个域如果完全不受控制的，该域称为自治的总之，图4.30对这些因素做了总结。,118,域有形域：是那些具有物理存在的域，如：人类用户，硬件无形域：包括软件以及其他非物质的对象，如：规则集成，百科全书。,119,2、问题框架调整域一旦有了特征，就可以很容易地检查域是否屣行了由选取的框架所施加的需求，继而结出有关那些框架的基本描述，其中包括它们每一个子域的特征。Jackson五种基本问题框架：工件、控制、信息、转换、连接,120,5.6.2 工件框架,典型例子：petri网图表处理工具,121,由此，子域具有以下一些特征：工件是动态的，惰性的同时也是无形的。操作请求也是动态的，但具有本能的主动性，并且是顺从的机器本身也是动态的、主动的、可编程的工件本身组成了一个“现实化”的域。,122,工件问题的例子：绘图工具计算机辅助软件工程工具许多实用的办公程序桌面出版以及网站开发工具工件问题的需求文档-表4.5需求文档包含了问题域的描述以及需求本身,123,5.6.3 控制框架,待求行为框架和稍微复杂的受控行为框架应用在系统或机器依照某一指定的行为规则集对问题域的某个组或部分的行为实施控制这样的一些场合。,124,1、待求行为框架行为规则：被操控系统的待求行为完全由一组预先确定的行为规则来定义受控域：可以是单一部件，或是若干子域。,125,2、受控行为框架在该变种内部，待求行为由用户通过命令方式加以控制而不是完全由预先确定的规则来决定。,126,行为规则：限制操作员所发布的命令并且定义被控系统的最终行为。用户：被假定为一个本能的自治域，该域可以随意发布命令。控制问题的相关例子电梯控制系统用于现代汽车工业的引擎管理系统用于温室环境控制系统安全或火警系统需求文档 表4.6,127,5.6.4 信息系统框架,两个变种：1、第一个变种稍微简单，是指系统自动地供应信息的情形框架图4.342、第二个变种中，信息以响应具体请求的方式提供，图4.35信息系统主要处理数据。实体部分可用数据模型来表示（ERD），也可以显示在“现实世界”子域框内，图4.36，左端线段：逻辑关系，右边线段：关系。问题域的“现实世界”部分 可能是一个静态域 也可能是一个动态域。注：信息系统并不对问题域施加控制。,128,信息系统的例子：YRR问题学生档案系统财务应用程序航空交通控制支持系统需求文档-表4.7,129,5.6.5 转换问题框架,130,这类框架对转换问题进行建模，即系统将某一特定格式的输入数据转换为与之对应的、另一种特定格式的输出数据。转换问题的例子钻孔文件转换程序人体扫描数据自动生成图片银行结帐报表自动计算薪金程序需求文档-表4.8,131,5.6.7 连接框架,应用在必须维持那些相互之间没有直接连接的子域间通信的场合分类：1、第一种应用在于使得你，在对连接域进行外部设计时有了一定的选择余地，图4.39另一种场景是连接域是给定的，且机器必须予以容纳的情形。图4.40需求文档-表4.9,132,5.6.8 待求子域性质,表4.10做了总结,133,编写需求,无论采用什么方法分析与描述问题域，标识并记录下实际的需求是十分必要的。需求必须予以陈述，使用文本来陈述需求。编写需求既是一种艺术，同时也要求相关的指南必须具有相当的概括性，其指导原则是：保持每个需求间相互分离。慎用情态动词使用现在进来陈述需求不包括细节,134,5.7 分析小结,一、分析的定义通过对问题域的研究，从而获得对问题域以及该域所包含的（待求解）问题特性的透彻理解并且文档说明。二、分析方法应当要求且便于描述以下几方面1、问题域的结构2、问题域的数据3、问题子域的因有属性及行为4、问题域中的重要事件及现象5、需求,135,三、不同的分析方法1、结构化分析初期：主要是围绕对数据流以及问题域的数据结构进行建模。现代：直接将重点放在开发解系统的模型。2、面向对象分析是当今主流方法，它要求所有的系统均按照对象的特点来建模，同时也继承了很多结构化分析的思想体系。3、面向问题域的分析：特点：重新将关注的重点定位问题域及需求上，以及通过对问题域加以分类，向分析人员提供具体问题的相关指南。,136,5.8需求文档,5.8.1 需求文档的目的把有关问题域的必要信息以及客户的需求从客户方（及与之关联的风险承担者）传达给解系统的设计者,137,582 需求文档的特性与风格,一、需求文档的特性1、较低的二义性2、良好 的组织3、完整性4、一致性5、可验证的6、可修改的,138,二、风格需求文档的特性可以通过建立良好的文档风格来实现，而良好风格的建立则必须充分考虑到客户及其相关的风险承担者的因素。确保客户可以对信息的准确性做检查这一点是至关重要的。可以采用相对形式化的描述和建模技术，无论采用何种技术，文本是扮演主要角色，具有良好逻辑结构的文档有助于对问题的理解。,139,583需求文档的内容及体系结构,通常情况下最好先以一段叙述性的原谅概要对问题域做一番简介应遵循Kovitz内容表中的各项原则应注意，普通的DD最适于定义与项目有关的术语，这当然包括那些存在问题域之中的各种不同数据。,140,需求文档内容的各个不同元素有助于确定该文档的大型体系结构。需求通常使用文本来记录，基本上采用列表的方式，适当地对需求做一些逻辑排序也可以，而其中一点是能够按照类型对需求加以划分。需求也决定着解系统所必须输出的结果，这方面作为DD补充来阐述。,141,有关需求文档的总体内容：文档细节问题域描述 概述 子域需求功能需求性能需求（速度、容量、可靠性、可用性）设计约束数据字典参考书目,142,一、文档细节标题、作者、文档说明约定/标准、版本、修改授权、修改历史、内容二、概述等同于“引言”，其目的是介绍主题并且为初次阅读的人建立相关上下文。,143,三、参考书目是指那些尤其与某个项目相关的参考材料，相关文档。包括：需求获取记录、有关交互系统的规格说明书，项目计划、质量保证计划、任何原有系统的用户手册、受设计约束制约的开发过程、系统必须满足的法定需求、有关目标硬件的规格说明书。四、词汇表（DD）五、索引索引有益于文档的导航浏览，而且通过使用上结现代化工具。相对比较易于实现和维护。,144,