软件工程第四章-形式化说明技术

2020/5/30,第四章形式化说明技术,1.非形式化方法：自然语言描述2.半形式化方法：数据流图或实体联系图3.形式化方法：基于数学技术描述,2020/5/30,2,本讲内容,概述有穷状态机Petri网Z语言小结,2020/5/30,4.1概述,2020/5/30,4,4.1.1非形式化方法的缺点,自然语言书写的系统规格说明书可能存在：1）矛盾；2）二义性；如：“操作员标识由操作员姓名和密码组成，密码由6位数字构成，当操作员登陆系统时它被存储在注册文件中。”3）含糊性；4）不完整性；5）抽象层次混乱。,2020/5/30,5,4.1.2形式化方法的优点,（1）数学是理想的建模工具，适合于表示系统状态和描述系统需求；（2）用数学表达的需求可在不同开发阶段平滑过渡。,2020/5/30,6,4.1.3应用形式化方法的准则,（1）选择合适的形式化方法；适用于当前项目（2）需要形式化，但不能过渡形式化，不能放弃传统的需求表达方法；（3）应该估算成本；（4）应该有形式化方法的专家提供指导；（5）不应该放弃传统的开发方法；,2020/5/30,7,3.1.1确定对系统的综合要求(2),5.接口需求用户接口、硬件接口、软件接口、通信接口、等。6.约束精度、工具和语言、设计约束、硬件约束、标准，等。7.逆向需求8.将来可能提出的要求,2020/5/30,8,3.1.2分析系统的数据要求,任何一个软件系统都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求的一个重要任务。通过建立数据模型来分析，如数据字典、层次方框图、Warnier图，并将数据结构规范化。,2020/5/30,9,3.1.3导出系统的逻辑模型,导出系统的详细的逻辑模型，通常包括数据流图、实体联系图、状态转换图、数据字典、主要的处理算法（IPO图）等。,2020/5/30,10,3.1.4修正系统开发计划,修订前期制定的开发进度计划、等。,2020/5/30,3.2与用户沟通获取需求的方法,2020/5/30,12,3.2.1访谈,1.正式访谈2.非正式访谈,当需要调查大量人员时，分发调查表,情景分析技术,能在某种程度上演示目标系统的行为，从而便于用户理解，而且还能进一步揭示出一些分析员目前不知道的需求。较易为用户所理解，能保证用户在需求分析过程中始终扮演一个积极主动的角色。,2020/5/30,13,观察用户工作流程或者实践,2020/5/30,14,用户和开发人员共同组成联合小组,加强联系促进交流增进合作,2020/5/30,15,借助数据流图、数据字典、IPO图等，细化、完善详细的数据流图，等到各处理环节对应的功能。,3.2.2面向数据流自顶向下求精,2020/5/30,16,3.2.3简易的应用规格说明技术,面向团队的需求收集法：（用户与开发者配合）初步访谈；开发者和用户分别写出“产品需求”；开会讨论，各自展示需求列表；得出一致意见，为需求列表制定小型规格说明；根据会议成果，起草完整的软件需求规格说明。,2020/5/30,17,3.2.4快速建立软件原型,快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。第一个特性是快速；第二个特性是容易修改。,快速建立能演示目标系统主要功能的程序。第四代技术可重用的软件构件形式化规格说明和原型环境,2020/5/30,3.3分析建模与规格说明,3.3.1分析建模,所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。简单地说，模型就是某一事物的抽象表示方式。为了开发复杂的系统，应从不同角度（模型）抽象出目标系统的特性（数据模型、功能模型、行为模型）。,2020/5/30,19,实体联系图：建立数据模型，描述数据对象及数据对象之间的关系；数据流图：建立功能模型的基础；状态转换图：描绘系统的状态和状态间转换的方式。,3.3.2软件需求规格说明,为了把用户的数据要求清楚、准确的描述出来，系统分析员通常建立一个概念性的数据模型。包含三种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。,2020/5/30,20,2020/5/30,21,数据对象可以是外部实体、事物、行为、事件、角色、单位、地点、结构等。属性定义了数据对象的性质。联系是数据对象之间相互连接的方式。（1）一对一联系（1：1）；（2）一对多联系（1：N）；（3）多对多联系（M：N）。,3.4实体-联系图,属性,联系,2020/5/30,22,实体-联系图,2020/5/30,23,通常用范式定义消除数据冗余的程度。第一范式（1NF）数据冗余度最大，第五范式（5NF）数据冗余度最小。但范式级别越高，(1)存储同样多数据需要分解成更多张表，“存储自身”的过程越复杂；(2)数据存储结构与基于问题域的结构间的匹配程度也随之下降，需求变化时数据稳定性下降；(3)需要访问的表增多，性能下降。(第三范式)第一范式：每个属性都是原子值第二范式：满足第一范式条件，每个关键字属性都仅有关键字决定第三范式：符合第二范式条件，每个非关键字属性都仅有关键字决定，并且一个非关键字属性值不依赖于另一个非关键字属性值,3.5数据规范化,2020/5/30,24,第一范式（1NF）数据冗余度最大，第五范式（5NF）数据冗余度最小。但范式级别越高，(1)存储同样多数据需要分解成更多张表，“存储自身”的过程越复杂；(2)数据存储结构与基于问题域的结构间的匹配程度也随之下降，需求变化时数据稳定性下降；(3)需要访问的表增多，性能下降。(第三范式)第一范式：每个属性都是原子值第二范式：满足第一范式条件，每个关键字属性都仅有关键字决定第三范式：符合第二范式条件，每个非关键字属性都仅有关键字决定，并且一个非关键字属性值不依赖于另一个非关键字属性值,3.6状态转换图,2020/5/30,25,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态图中定义的状态主要有：初态、中态、中间状态事件是某个特定时刻发生的事情，它是引起系统做动作或状态转换的控制信息。,3.6状态转换图,2020/5/30,26,闲置,拨号音do:响拨号音,超时do:响蜂鸣音,存储的信息do:播放信息,接通中do:试接通,振铃do:振铃,拨号,通话,断线,忙音do:响忙音,挂断电话,挂断电话,拿起话筒,超时,无效号码,有效号码,超时,数字,数字,占线,已接通,受话人回话,受话人挂断电话,信息播完,2020/5/30,3.7其他图形工具,3.7.1层次方框图,2020/5/30,28,例如，描绘一家计算机公司全部产品的数据结构可以用图中的层次方框图表示,层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素（不能再分割的元素）。,3.7.1层次方框图,2020/5/30,29,随着结构的精细化，层次方框图对数据结构的描绘也越来越详细，这种模式非常适合于需求分析阶段的需要。统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节为止。,3.7.2Warnier图,2020/5/30,30,法国计算机科学家Warnier提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，Warnier图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。用Warnier图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息量是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把Warnier图转变成软件设计的工具。,3.7.2Warnier图,2020/5/30,31,花括号：区分数据结构的层次，在一个花括号内的所有名字都属于同一类信息。异或符号：表明一类信息或一个数据元素在一定条件下才出现，而且在这个符号上、下方的两个名字所代表的数据只能出现一个。圆括号：中间的数字指明了这个名字代表的信息类（或元素）在这个数据结构中重复出现的次数。,3.7.3IPO图,2020/5/30,32,IPO图是输入/处理/输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、数据处理和输出数据之间的关系。左框：列出输入数据。中框：列出主要的处理（次序暗示了执行的顺序）。右框：列出输出数据粗大箭头：指出数据通信的情况。,用IPO图描绘主文件更新功能,3.7.3IPO图,2020/5/30,33,建议使用一种改进的IPO图（也称为IPO表），这种图中包含某些附加信息，比原始的IPO图更有用。改进的IPO图中包含的附加信息，主要有系统名称，图的作者，完成本图的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清单，本模块调用的模块的清单，注释，以及本模块使用的局部数据元素等。,3.7.3IPO图,2020/5/30,34,在需求分析阶段可以使用IPO图简略地描述数据流图中各个处理的基本算法（着重说明处理功能而不是具体实现功能的算法）。当然，在需求分析阶段，IPO表中的许多附加信息暂时还不具备。但是，在软件设计阶段可以进一步补充、修正这些表，继续作为设计阶段的文档。这正是在需求分析阶段用IPO表作为描述基本算法的工具的重要优点。,2020/5/30,3.8验证软件需求,3.8.1从哪些方面验证软件需求的正确性,2020/5/30,36,需求分析阶段的工作结果是开发软件系统的重要基础；统计表明，软件系统中15%的错误起源于错误的需求；需求的正确性从四个方面验证：一致性完整性现实性有效性,3.8.2验证软件需求的方法,2020/5/30,37,验证需求的一致性人工技术审查软件系统规格说明书的正确性；人工审查的效果难以保证，进行形式化描述，用软件工具验证。验证需求的现实性参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。验证需求的完整性和有效性开发原型系统