广告行业包括网站建设吗,永久免费搭建网站,那些影视解析网站怎么做的,电销防封号系统软 件 工 程 笔 记 第一章 一个软件产品必须由一个完整的配置组成#xff0c;软件配置主要包括#xff1a;程序#xff0c;数据及相关文档。程序是能够完成预定功能和性能的可执行的指令序列#xff1b;数据是使程序能够适当的处理信息的数据结构#xff1b;文档是开发使… 软 件 工 程 笔 记 第一章 ² 一个软件产品必须由一个完整的配置组成软件配置主要包括程序数据及相关文档。程序是能够完成预定功能和性能的可执行的指令序列数据是使程序能够适当的处理信息的数据结构文档是开发使用和维护程序所需要的图文资料。 ² 软件危机的定义软件危机是指在计算机软件开发、使用、维护过程中遇到的一系列严重问题和难题。它包括两方面1.如何开发软件以满足对软件日益增长的要求 2.如何维护数量不断膨胀的已有软件 ² 软件危机的具体表现1. 对软件开发成本和进度的估计往往很不准确 2. 用户对“已完成”的软件系统不满意的现象经常发生 3. 软件产品的质量往往靠不住 4. 软件常常是不可维护的 5. 软件通常没有是适当的文档资料 6. 软件成本在计算机系统总成本中所占的比例逐年上升 7. 软件开发生产率提高的速度往往跟不上计算机应用迅速普及的深入的速度 ² 软件危机出现的原因1. 来自软件自身的特点。是逻辑部件缺乏可见性规 模庞复杂修改维护困难 2. 软件开发与维护的方法不当。忽视需求分析认为软件开发等于程序编写轻视软件维护 3. 供求矛盾将是一个永恒的主题。面对日益增长的软件需求人们显得力不从心 ² 软件工程的定义软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理。、技术和方法来开发和维护软件把经过时间考验而证明正确的管理技术和当前能够的到的最好的技术方法结合起来以经济的开发出高质量的软件并有效的维护它这就是软件工程。 ² IEEE对软件工程的定义软件工程是1把系统的规范的可度量的途径应用于软件开发、运行和维护过程也就是把工程应用于软件2研究1中所提到的途径。 ² 软件工程的本质特征1. 软件工程关注于大型程序的构造 2. 软件工程的中心课题是控制复杂度 3. 软件经常变化 4. 开发软件的效率非常重要 5. 和谐的合作是开发软件的关键 6. 软件必须有效的支持他的用户 7. 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品 ² 消除软件危机的途径1. 对计算机软件有一个正确的认识软件程序 2. 必须充分认识到软件开发不是某种个体劳动的神秘技巧而应该是一种组织良好、结构严密、各类人员协同配合、共同完成的工程项目 3. 推广使用在实践中总结出来的开发软件的成功技术和方法 4. 开发和使用良好的软件工具 ² 软件工程的基本原理1. 用分阶段的生命周期计划严格管理 2. 坚持进行阶段评审 3. 实行严格的产品控制 4. 采用现代程序设计技术 5. 结果应该清楚的审查 6. 开发小组的人员应该少而精 7. 承认不断改进软件工程实践的必要性 ² 软件工程包括管理和技术两方面的内容 ² 软件工程方法学定义通常把在软件生命周期全过程中使用的一整套技术方法的集合称为软件工程方法学。 ² 软件工程方法学包含三个因素方法、工具和过程 ² 软件工程方法学分为传统方法学生命周期方法学或结构化范型和面向对象方法学面向对象范型 ² 面向对象范型的要点1. 把对象作为融合了数据及在数据上的操作行为的统 一的软件构件 2. 把所有的对象都划分成类 3. 按照父类或称为基类与子类或称为派生类的关系把若干个相关类组成一个层次结构的系统也称为类等级 4. 对象彼此间仅能通过发送消息互相联系 ² 结构化范型的优点把软件生命周期划分为若干个阶段每个阶段的任务相对独立而且比较简单便于不同人员的分工协作从而降低了整个软件开发过程的困难程度 ² 结构化范型的缺点当软件规模庞大时或者对软件的需求是模糊的或会因为时间而变化时开发出的软件往往不成功而且维护起来依然很困难 ² 面向对象范型的优点降低了软件产品的复杂性提高了软件的可理解性简化了软件的开发和维护工作促进了软件重用 ² 软件工程与软件工程方法学有何关系软件工程是为了开发出高质量的软件产品所需完成的一系列任务的框架他规定了完成各项任务的工作步骤。而后者通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学也称范型。 软件工程是软件工程方法学的三个重要组成部分之一。 ² 什么是软件生命周期模型软件生命周期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。 ² 软件生命周期模型由软件定义问题定义可行性研究需求分析软件开发总体设计详细设计编码与单元设计综合测试运行维护 ² 软件定义阶段要回答的关键问题是“要解决的问题是什么”可行性研究阶段要回答的关键问题是“对于上一个阶段所确定的问题有行得通的解决办法吗”需求分析阶段的任务仍不是解决问题而是准确的确定“为了解决这个问题目标系统必须做什么”总体设计阶段回答的关键问题是“概括的说应该怎样实现目标系统”详细设计阶段把解法具体化回答“应该怎样具体的实现这个系统呢”编码和单元测试的关键任务时写出正确的容易理解、容易维护的程序模块综合测试的关键任务是通过各种类型的测试及相应的调试使软件达到预定的要求 ² 运行维护的实质对比可行性研究实质一次压缩和简化了的定义和开发过程。维护时期不在进一步划分阶段 ² 瀑布模型的优点它提供了一个模板这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。虽然有不少缺陷但比在软件开发过程中随意的状态要好的多 ² 瀑布模型的缺点1. 实际的项目大部分情况难以按照该模型给出的顺序执行 而且这种模型的迭代是间接的这很容易由微小的变化 而造成大的混乱 2. 经常情况下客户难以表达真正的需求而这种模型却要求如此这种模型是不欢迎二义性存在的 3. 客户要等到开发的晚期才能看到程序运行的测试版本而在这是发现大的错误时可能引起客户的惊慌而后果也可能是灾难性的 ² 瀑布模型的特点1. 阶段间具有顺序性与依赖性 2. 推迟实现的观点 3. 质量保证的观点1每个阶段都必须完成规定的文档2每个阶段结束前都应该对所完成的文档进行评审以便尽早发现问题改正错误 ² 快速原型模型优点使用户能够感受到实际的系统使开发者能够快速的构造出系统的框架 ² 快速原型模型的缺点产品的先天性不足因为开发者常常需要做实现上的折中可能采用不合适的操作系统或程序设计语言以使原型能够尽快工作 ² 增量模型的优点1. 人员分配灵活刚开始不用投入大量的人力资源当核 心产品很受欢迎时可增加人力实现下一个增量 2. 当配备的人员不能在设定的期限内完成产品时他提供了一种先推出核心产品的途径这样就可以先发布部分功能给客户对客户起到镇定剂的作用。 ² 增量模型的缺点自始至终开发者和客户纠缠在一起知道完全版本出来适用于软件需求不明确设计方案有一定风险的软件项目 ² 增量模型最佳分解的方法因软件产品特点和开发人员的习惯而异。分解时唯一必须遵守的约束条件是当把新构件集成到现有软件中时所形成的产品必须是可测试的 ² 螺旋模型的基本思想使用原型及其他方法来尽量降低风险 ² 螺旋模型的优点对于大型系统及软件的开发这种模型是一个很好的方法开发者和客户能够较好的对待和理解每一个演化级别上的风险 ² 螺旋模型的缺点1 需要相当的风险分析评估的专门技术且成功依赖于这 种技术。 2 很明显一个大的没有被发现的风险问题将会导致问题的发生可能导致演化的方法失去控制 3 这种模型相对比较新应用不广泛其功效需要进一步验证 适用于内部开发的大规模软件项目 ² 需求分析阶段应该用正式的文档准确地记录对目标系统的需求这份文档通常称为“规格说明书” ² 螺旋模型瀑布模型增量模型 ² 螺旋模型由风险驱动 ² 为什么说喷泉模型较好的体现了面向对象软件开发过程无缝和迭代的特性 因为使用面向对象方法学开发软件时各个阶段都使用统一的概念和表示符号因此整个开发过程都是吻合一致的或者说是无缝连接的这自然就很容易实现各个开发步骤的反复多次迭代达到认识的逐步深化而喷泉模型则很好的体现了面向对象软件开发过程迭代和无缝的特性。 ² Rational统一过程的优点提高团队生产力在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面针对所有关键的开发活动为每个开发成员提供了必要的准则。模板和工具指导并确保全体成员共享相同的知识基础。他建立了简洁和清晰的过程结构为开发过程提供较大的通用性。 ² Rational统一过程的缺点RUP只是一个开发过程并没有涵盖软件过程的全部内容例如它缺少关于软件运行和支持等方面的内容此外他没有支持多项目的开发结构这在一定程度上降低了在开发组织内大范围实现重用的可能性。 ² Rational统一过程主要适用于“大型的需求不断变化的复杂软件系统项目” ² 敏捷过程适用于“商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束” ² 微软过程适用于“商业环境下具有有限资源和有限开发时间约束的项目的软件过程模式” 第二章 v 可行性研究的必要性原因开发一个软件时需要判断原定的系统模型和目标是否实现系统完成后所能带来的效益是否大到值得开发投资这个系统的程度如果做不到这些那么花费在这个工程上的任何时间、人力、软硬件资源和经费都是无谓的浪费。可行新研究的实质是在较高层次上以较抽象的方式进行的系统分析和设计的过程可行性研究的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决。 v 可行性研究的目的用最小的代价在尽可能短的时间内确定问题是否能够解决。 v 可行性研究的目的不是解决问题 v 可行性研究的实质进行一次大大压缩简化了的系统分析与设计的过程也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。 v 可行性研究的内容1. 技术可行性对要开发项目的功能、性能和限制条件进行分析确定在现有的资源条件下技术风险有多大项目能否实现 2. 经济可行性进行开发成本的估算以及了解取得效益的评估确定要开发的项目是否值得投资开发 3. 操作可行性系统的操作方式在这个用户组织内是否行得通 4. 社会可行性 5. 社会效益 6. 法律 v 可行性研究的任务对以后的行动方针提出建议。 v 可行性研究时间的长短取决于工程的规模 v 可行性研究的成本是预计的工程总成本的5%~10% v 可行性研究的过程1. 复查系统规模与目标确保分析员正在解决的问题时要求他 解决的问题 2. 研究正在使用的系统 3. 导出新系统的高层逻辑模型 4. 进一步定义问题根据逻辑模型 与用户一起发现和改正错误 前四步构成了一个循环 5. 导出和评价供选择的解法 6. 推荐行动方针 7. 草拟开发计划给出需求分析阶段的进度表 8. 书写文档提交审查 v 逻辑模型包括数据流图和数据字典 v 拟定开发计划阶段拟定需求分析进度表 系统流程图 v 数据流图DFD是一种图形化技术他描述信息流和数据从输入移动到输出的过程中经受的变化 v 设计数据流图时只需要考虑系统必须完成的基本逻辑功能 v 数据流图中应该描绘出所有可能的数据流向而不应该描绘出现某个数据流的条件 v 数据流图中忽略出错处理 v 星号*表示“与”的关系 加号表示“或”的关系 圆圈加表示互斥的关系 v 数据流图有四个成分源点或终点 处理 数据存储 数据流 v 数据流图命名是先为数据流命名再为处理命名 如果对数据流命名是遇到了困难 可能是对数据流图分解的不恰当 v 数据流图中的处理应不超过9个 超过时就不易理解 应分层或画分图 v 数据流图的作用1. 交流信息的工具。分析员把他对现有系统或对目标系统的设想用数据流图描绘出来供有关人员审查确认 2. 作为分析和设计的工具 v 数据字典定义数据字典是关于数据的信息的集合也就是对数据流图中包含的所有元素的定义的集合 v 数据字典的作用作为分析阶段的工具在软件分析和设计的过程中给人提供关于数据的描述的信息 v 逻辑模型包括数据流图 数据字典 v 数据字典的内容1.数据流 2.数据流分量 3.数据存储 4.处理(对比数据流图四成分) v 数据字典主要由对数据的定义组成因为对数据的处理用其他工具IPO图或PDL描述更方便 v 数据字典中对数据的定义主要包括一般信息定义使用特点控制信息分组信息 v 数据字典中数据定义的实质是对数据进行一次自顶向下的分解 v 数据元素组成数据的方式有四种顺序 重复 选择 可选 v 等价于/定义为 v 和/连接两个分量 v [ ] 选择一个 通常用‘|’隔开供选择的分量 v { } 重复 重复花括号内的分量 有上下界 表示重复次数的上下界 v ( ) 可选 即圆括号内的分量可有可无 v 成本效益分析的目的是从经济角度分析开发一个新系统是否划算从而帮助客户组织的负责人正解的做出是否投资于这项开发工程的决定 v 成本估计技术代码行技术 任务分解技术 自动估计成本技术 v 数据流图与数据字典的关系数据流图与数据字典共同构成系统的逻辑模型没有数据字典数据流图就不严格没有数据流图数据字典也难以发挥作用 第三章 ü 需求分析的目的/意义/必要性为了开发出真正满足用户需求的软件产品首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件不论我们把设计和编码工作做得如何出色不能真正满足用户需求的程序只会令用户失望给开发者带来烦恼。 ü 需求分析的任务确定对系统的综合要求 1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求 分析系统的数据要求分析系统的数据结构图形工具描 述数据结构[层次方框图和Warnier图]数据结构规范化 导出系统的逻辑模型数据流图实体联系图状态转换 图数据字典和主要的处理算法描述 修正系统开发计划 ü 与用户沟通获取真实需求的的方式1. 访谈 2. 面向数据流自顶向下求精 3. 简易的应用规格说明技术 4. 快速建立软件原型 ü 需求分许是软件定义的最后一个阶段他的主要任务时准确回答“系统必须做什么”这个问题不是确定系统怎样完成他的工作 ü 需求分析结束之前应出具软件需求规格说明书书面形式准确描述软件的需求 ü 需求分析方法准则1. 必须理解并描述问题的信息域根据这条准则应该建 立数据模型 2. 必须定义软件应完成的功能这条准则要求建立功能模型 3. 必须描述作为外部事件结果的软件行为这条准则要求建立行为模型 4. 必须对描述信息、功能、行为的模型进行分解用层次的方式展示细节 ü 出错处理的定义在某些情况下出错处理指的是当应用系统发现它自己犯下一个错误时所采取的行动。有时也指系统对环境错误的响应 ü 对应用系统本身的检测应该仅限于系统的关键部分并且应该尽可能的少 ü 接口需求定义描述应用程序与它的环境通信的格式 ü 环境即使用该系统的外界因素 ü 约束设计约束或实现约束描述在设计或实现应用系统是应遵守的限制条件 ü 情景分析情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行进行分析 ü 情景分析的用处好处意义1. 他能在某种程度上演示目标系统的行为 从而便于用户理解而且还可能进一步揭示 出一些分析员目前还不知道的需求 2. 由于情景分析较易为用户所理解使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色 ü 分析系统的数据要求通常采用建立数据模型的方式 ü 辅助描述数据结构常用的图形工具有层次方框图和Warnier图 ü 需求分析的目标之一就是把数据流和数据存储定义到元素级 ü IPO图简明的描述了算法 ü 通过功能分解可以完成对数据流图的细化 ü 简易的需求规格说明技术是一个面向团队的需求收集法 ü 简明的需求规格说明技术的优点是开发者和用户不分彼此齐心协力密切合作计时讨论并求精有能导出规格说明的具体步骤 ü 快速建立软件原型是最有效最强大的需求分析技术 ü 快速原型的定义快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序 ü 快速原型的特点1. 快速 2 容易修改 ü 建立快速原型的目的尽快向用户提供一个可在计算机上运行的目标系统的模型以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快的达成共识 ü 快速的构建和修改原型通常使用下述3种方法和工具 1. 第四代技术 2 可重用的软件构件 3 形式化规格说明和原型环境 形式化说明技术第四章讲 ü 模型的定义为了理解事物而对事物做出的一种抽象是对事物的一种无歧义的书面描述。通常模型由一组图形符号和组织这些符号的规则组成 ü 需求分析阶段应该建立三种模型根据需求分析方法准则 1. 数据模型实体联系模型 2. 功能模型数据流图 3. 行为模型状态图即状态转换图 ü 形式化方法的必要性1. 为了消除用自然语言书写的软件规格说明书中可能 存在的不一致性、歧义、含糊、不完整及抽象层次混 乱等问题。 2 在需求验证阶段对于规模庞大的系统方便人工 审查需求一致性 ü 数据对象是对软件必须理解的复合信息的抽象仅有单个值的事物不是数据对象 ü 复合信息具有一系列不同性质或属性的事物 ü 数据对象只封装了数据而没有对施加于数据上的操作的引用。区别于面向对象范型是将数据与操作封装在一起 ü ER图中包含了“实体关系和属性”3种基本成分。矩形框代表实体圆弧矩形代表属性 ü ER模型的优点1. ER模型比较接近人的习惯思维方式 2 ER模型使用简单的图形符号表达系统分析员对问题域的 理解不熟悉计算机技术的用户也能理解它 3 ER模型可以作为用户与分析员之间有效的交流工具 ü 数据规范化的目的减少数据冗余避免出现插入异常或删除异常简化修改数据的过程 ü 范式级别越高随之而来的一些列问题1. 存储同样的数据就需要分解成更多 的表因此“存储自身”的过程也 就越复杂 2 数据的存储结构与基于问题域的结 构件间的匹配程度也随之下降因 此需求变化时数据源的稳定性较差 3 范式级别提高需要访问的表增多因此性能将下降 ü 实用角度来看大多数场合实用第三范式 ü 状态转换图的定义状态转换图简称状态图通过描绘系统的状态及引起系统状态转换的事件来表示系统的行为。此外状态图还指明了作为特定事件的结果系统将做哪些动作 ü 状态状态是任何可以被观察到的系统行为模式一个状态代表系统的一种行为模式 ü 事件在某个特定时刻发生的事情他是引起系统做动作或从一个状态转换到另一个状态的外界事物的抽象简言之就是引起系统做动作或装换状态的控制信息 ü 状态图三部分上面是状态的名称中间是状态变量的名字和值下面是活动表 ü Warnier图与层次方框图的区别前者可以指出一类信息或一个信息元素是重复出现的也可以表示特定信息在某一类信息中是有条件的出现的。 ü IPO图的好处方便的描述输入数据对数据的处理和输出数据之间的关系软件设计阶段可以进一步补充修正这些图作为设计阶段的文档 ü 软件需求验证的四方面1 一致性。所有需求必须是一致的任何一条需求 不能和其他需求相互矛盾 2 完整性。需求必须是完整的需求规格说明是必须包含用户需要的每一个功能 3 现实性。制定的需求必须是在现有的硬件技术和软件技术基本上可以实现的 4 有效性。必须证明需求是正确有效的确实能解决用户面对的问题 ü 需求验证的方法1 一致性。人工技术审查 2 现实性。仿真或性能模拟技术 3 完整性和有效性。请用户试用成本高使用原型系统 ü 需求分析软件工具的要求1. 必须有形式化的语法或表 2 使用这个软件工具能够导出详细的文档 3 必须提供分析测试规格说明书的不一致性 性和冗余性的手段并且能够产生一组报告指明 对完整性分析的结果 4 能够改进通信状况 ü FSL/PSA系统的主要优点它改进了文档质量能保证文档具有完整性、一致性和无二义性从而可以减少管理和维护的费用。数据存放在数据库中。便于增加、删除和更改这也是他的一个优点。 第五章 ² 总体设计的必要性可以站在全局高度上花较少成本从较抽象的层次上分析对比多种可能的系统实现方案和软件结构从中选出最佳方案和最合理的软件结构从而用较低成本开发出较高质量的软件系统。 ² 总体设计的过程主要由两个阶段组成系统设计阶段确定系统的具体实现方案 结构设计阶段确定软件结构 1. 设想供选择的方案从数据流图出发 2. 选取合理的方案低成本中成本高成本对于每一种方案应准备系统流程图组成系统的物理元素清单成本效益分析实现这个系统的进度计划 3. 推荐最佳方案第一阶段至此完成 4. 功能分解 5. 设计软件结构 6. 设计数据库 7. 制定测试计划 8. 书写文档系统说明、用户手册、测试计划、详细的实现计划、数据库设计结果 9. 审查和复查 ² 软件设计过程中应该遵循的基本原理1. 模块化。模块是由边界元素限定的相邻程序 元素例如数据说明可执行的语句的序列而且有一个总体标识符代表它。模块是构成程序的基本构件。模块化就是把程序划分成独立命名且可独立访问的模块每个模块完成一个子功能把这些模块集成起来构成一个整体可以完成指定的功能满足用户的需求 2. 抽象。抽象出事物的本质特征而暂时不考虑他们的细节一个复杂的动态系统首先可以用一些高级的抽象概念构造和理解这些高级的概念又可以用一些低级的概念构造和理解。 3. 逐步求精。为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。事实上可以把逐步求精看作是一项把一个时期内必须解决的种种问题按优先级排序的技术 4. 信息隐藏和局部化。所谓局部化是指把一些关系密切的软件元素物理的放的彼此靠近。所谓隐藏不是隐藏关于模块的一切信息而是模块的实现细节 5. 模块独立开发具有独立功能而且和其他模块之间没有过多的交互作用的模块就可以做到模块独立 ² 模块化的优点1. 可以使软件结构清晰不仅容易设计也容易阅读和理解 2. 使软件容易测试和调试因而有助于提高软件的可靠性 3. 能够提高软件的可修改性 4. 有助于软件开发工程的组织管理 ² 抽象与求精的联系与区别抽象与求精是一对互补的概念。抽象使得设计者能够说明过程和数据同时却忽略了底层细节。事实上可以把抽象看做是一种通过忽略多余的细节同时强调有关的细节而实现逐步求精的方法。求精则帮助设计者在设计过程中揭示出底层细节。 ² 模块独立的好处重要性第一有效的模块化(即具有独立的模块)的软件比较容易开发出来。这是由于能够分割功能而且接口可以简化当许多人分工合作开发同一个软件时这个优点尤其重要。第二独立的模块比较容易测试和维护。这是因为相对说来修改设计和程序需要的工作量比较小错误传播范围小需要扩充功能时能够“插入”模块。 ² 耦合和内聚的区别与联系是模块独立程度的两个标准度量。耦合衡量不同模块彼此间互相依赖(连接)的紧密程度内聚衡量一个模块内部各个元素彼此结合的紧密程度。内聚和耦合是紧密相关的模块内的高内聚往往意味着模块间的松耦合 ² 设计时应该力求做到低耦合和高内聚 ² 耦合的概念耦合衡量不同模块彼此间互相依赖(连接)的紧密程度。 ² 数据耦合两个模块彼此间通过参数交换信息而且交换的信息仅仅是数据 ² 控制耦合两个模块间传递的信息中有控制信息出现时这种耦合称为控制耦合 ² 控制耦合一般可以通过适当分解用数据耦合代替它 ² 特征耦合当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时就出现了特征耦合 ² 公共环境耦合当两个或多个模块通过一个公共数据环境相互作用时他们之间的耦合称为公共环境耦合 ² 内容耦合:一个模块可以直接调用另一模块中的数据或者允许一个模块直接转移到另一个模块中去。 ² 耦合的使用原则尽量使用数据耦合少用控制耦合和特征耦合限制公共环境耦合的范围完全不用内容耦合 ² 内聚的概念内聚衡量一个模块内部各个元素彼此结合的紧密程度它是信息隐藏和局部化概念的自然扩展。 ² 偶然内聚一个模块完成一组任务这些任务间彼此即使有关系关系也是很松散的就叫做偶然内聚。低内聚 出现错误的概率最高 ² 如果一个模块完成的任务在逻辑上属于相同或相似的一类则称为逻辑内聚低内聚。 修改较困难 ² 时间内聚一个模块包含的任务必须在同一段时间内执行低内聚 ² 过程内聚一个模块内的处理元素是相关的而且必须以特定次序执行则称为过程内聚中内聚 ² 通信内聚模块中所有元素都使用同一个输入数据和产生同一个输出数据则称为通信内聚中内聚 ² 顺序内聚一个模块内的处理元素和同一个功能密切相关而且这些处理必须顺序执行则称为顺序内聚。高内聚 ² 功能内聚模块内所有处理元素属于一个整体完成一个单一功能则称为功能内聚最高程度的内聚 ² 软件设计的启发式规则1. 改进软件结构提高模块独立性 2. 模块规模应该适中 3. 深度、宽度、扇出和扇入都应适应 4. 模块的作用域应该在控制域之内 5. 力争降低模块接口的复杂程度 6. 设计单入口单出口的模块 7. 模块功能应该可以预测 ² 一个设计的好的点醒系统的平均扇出应该是3~4 上限应该是5~9 ² 启发式规则只是经验之谈既不是总体设计的目标也不是应该遵循的普遍原理 ² 在结构图中箭头表示传递的信息尾部是空心圆表示传递的是数据实心圆表示传递的是控制信息 ² 面向数据流的设计方法的目标是给出设计软件结构的一个系统化的途径 ² 面向数据流的设计方法把信息流映射成软件结构信息流的类型决定了映射的方法 ² 变换流信息沿输入通路进入系统同时由外部形势变换成内部形势进入系统的信息通过变换中心经加工处理之后再沿输出通路变换成外部形势离开软件系统 ² 事务流完成的任务1. 接收输入数据输入数据又称为事务 2. 分析每个事务以确定它的类型 3. 根据事务类型选取一条活动通路 ² 变换分析的步骤把具有变换流特点的数据流图按预先确定的模式映射成软件结构 1. 复查基本数据模型 2. 复查并精化数据流图 3. 确定数据流图具有变换特性还是事务特性 4. 确定输入流和输出流的边界从而孤立出变换中心 5. 完成第一级分解 6. 完成第二级分解 7. 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化 ² 变换分析与事务分析的选择如果数据流不具有显著的事务特点最好使用变换分析反之如果具有明显的事务中心则应该采用事务分析技术。但是机械地遵循变换分析或事务分析的映射规则很可能会得到一些不必要的控制模块如果它们确实用处不大那么可以而且应该把它们合并。反之如果一个控制模块功能过分复杂则应该分解为两个或多个控制模块或者增加中间层次的控制模块。 第六章 v 详细设计阶段的任务定应该怎样具体地实现所要求的系统也就是说经过这个阶段的设计工作应该得出对目标系统的精确描述从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。 v 衡量程序的质量不仅要看他的逻辑是否正确性能是否满足要求更主要的是看他是否容易阅读和理解结构程序设计技术 v 只用三种基本的控制结构就可以实现任何单入口单出口的程序顺序选择循环 v 结构程序设计的定义结构程序设计是尽可能少用GO TO语句的程序设计方法。最好仅在检测出错误时才使用GO TO语句而且应该总是使用前向GO TO语句。 v 经典的结构程序设计顺序、选择、循环 扩展的结构程序设计并且允许do-case、do-until 修正的结构程序设计并且允许leave、break v 人机界面设计遇到的问题1. 系统响应时间 2. 用户帮助设施 3. 出错信息处理 4. 命令交互 v 响应时间从用户完成某个控制动作到软件给出某个预期的响应之间的这段时间 v 响应时间的两个基本属性长度和易变性 v 过程设计工具可以分为图像表格语言 v 程序流程图的主要缺点1. 程序流程图本质上不是逐步求精的好工具它诱使程序员 过早地考虑程序的控制流程而不去考虑程序的全局结构。 2. 程序流程图中用箭头代表控制流因此程序员不受任何约束可以完全不顾结构程序设计的精神随意转移控制。 3. 程序流程图不易表示数据结构。 v 盒图的特点1. 功能域(即一个特定控制结构的作用域)明确可以从盒图上一眼就看出 来 2. 不可能任意转移控制 3. 很容易确定局部和全程数据的作用域 4. 很容易表现嵌套关系也可以表示模块的层次结构 v PAD图的优点1. 使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构 化程序。 2. PAD图所描绘的程序结构十分清晰。图中最左面的竖线是程序的主线即第一层结构。随着程序层次的增加PAD图逐渐向右延伸每增加一个层次图形向右扩展一条竖线。PAD图中竖线的总条数就是程序的层次数。 3. 用PAD图表现程序逻辑易读、易懂、易记。PAD图是二维树形结构的图形程序从图中最左竖线上端的结点开始执行自上而下从左向右顺序执行遍历所有结点。 4. 容易将PAD图转换成高级语言源程序这种转换可用软件工具自动完成从而可省去人工编码的工作有利于提高软件可靠性和软件生产率。 v 判定表的优点清晰的表示复杂的条件组合与应做的动作之间的对应关系 v 判定表的缺点不适合作为一种通用的设计工具没有一种简单的方法使它能同时清晰的表示顺序和重复等处理特性 v 以上为图或表的形式来描述过程设计语言描述过程设计的是“过程设计语言” v 过程设计语言PDL的特点1. 关键字的固定语法它提供了结构化控制结构、数据 说明和模块化的特点。 2. 自然语言的自由语法它描述处理特点。 3. 数据说明的手段。应该既包括简单的数据结构(例如纯量和数组)又包括复杂的数据结构(例如链表或层次的数据结构)。 4. 模块定义和调用的技术应该提供各种接口描述模式。 v 过程设计语言的优点1. 可以作为注释直接插在源程序中间。这样做能促使维护人员 在修改程序代码的同时也相应地修改PDL注释因此有助于保持 文档和程序的一致性提高了文档的质量。 2. 可以使用普通的正文编辑程序或文字处理系统很方便地完 成PDL的书写和编辑工作。 3. 已经有自动处理程序存在而且可以自动由PDL生成程序代 码。 v PDL的缺点是不如图形工具形象直观描述复杂的条件组合与动作间的对应关系时不如判定表清晰简单。 v 面向数据结构设计方法的最终目标是得出对程序处理过程的描述 v Jackson图面向数据结构的设计方法选择顺序循环 v Jackson程序设计方法的步骤1. 分析并确定输入数据与输出数据的逻辑结构并用Jackson图描绘这些数据结构2. 找出输入数据结构与输出数据结构中有对应关系的数据单元3. 从描绘数据结构的Jackson图导出描绘程序结构的Jackson图4. 列出所有操作和条件并且把他们分配到程序结构图的适当位置5. 用伪码表示程序 v 程序复杂程度定量度量的必要性把程序的复杂程度乘以适当常数即可估算出软件中错误的数量以及软件开发需要用的工作量定量度量的结果可以用来比较两个不同的设计或两个不同算法的优劣程序的定量的复杂程度可以作为模块规模的精确限度 v McCabe计算环形复杂度V(g) E-N2 E是边数 N是点数 v *** 环形复杂度的上限是10 v Halstead预测程序长度 H n1*log2(n1)n2*log2(n2) 预测程序中包含错误个数 E N*log2(n1n2)/3000 其中n1表示不同运算符的个数 n2表示不同操作数的个数 N1表示运算符出现的总次数 N2表示操作数出现的总次数 NN1N2 第七章 n 实现包括编码和测试 n 程序的质量主要取决于软件设计的质量 n 测试的必要性如果在软件投入生产性运行之前没有发现并纠正软件中的大部分差错则这些差错迟早会在生产过程中暴露出来那是不仅改正这些错误的代价更高而且往往会造成很恶劣的后果 n 测试的目的尽可能多的发现并排除软件中潜藏的错误最终把一个高质量的软件系统交给用户使用 n 判断题测试阶段的任务是发现错误 x 并改正错误 n 选择程序设计语言的主要实用标准1. 系统用户的要求 2. 可以是使用的编译程序 3. 可以得到的软件工具 4. 工程规模 5. 程序员的知识 6. 软件可移植性要求 7. 软件的应用领域 n 源代码编写规则1. 程序内部的文档。程序内部应包含必要的标识符、适当的注释、 和程序的视觉组织等 2. 良好的数据说明风格。数据说明的次序应该标准化 3. 简单而直接的语句构造 4. 输入输出具有规则 5. 具有较高的效率。效率主要是指处理机时间和存储器容量两个方面 n 软件应该像对他要求的那样有效而不应该如同人类可以做到的那样有效 n 效率是靠好设计来提高的不要牺牲程序的清晰性和可读性来提高效率 n 软件测试的准则1. 所有测试都应该能追溯到用户需求 2. 应该远在测试开始之前就制定出测试计划 3. 把Pareto原理应用到软件测试中 4. 应该从小规模测试开始并逐步进行大规模测试 5. 穷举测试是不可能的 6. 为了达到最佳的测试效果应该由独立的第三方从事测试工作 7. 程序修改后要回归测试 8. 应长期保留测试用例直至系统废弃 n 测试分为静态测试和动态测试区别在于是否实际运行软件静态分为人为和计算机辅助动态分为黑盒白盒 n 黑盒测试的又称功能测试 n 白盒测试又称结构测试 n 测试的步骤1. 模块测试。把每个模块当做一个单独的实体来测试 2. 子系统测试。把经过单元测试的模块当做一个子系统来测试主要测试模块间的协调和通信因此这个阶段着重测试接口 3. 系统测试。发现软件设计中的错误或需求说明中的错误 4. 验收测试。需要用户参与往往发现的是需求说明书中的错误 5. 平行运行。同时运行新旧系统 n 模块测试是对每个单独的模块分别采用黑盒和白盒测试技术测试他的功能是否正确检查模块控制结构中的特定路径并发现最大数量的错误 n 模块测试的特点是主要应用白盒测试技术并且多个模块可以并发的进行 n 验收测试又称确认测试目的是验证系统确实能满足用户的需要 n 平行运行的目的1. 可以在准生产环境下运行新系统而又不冒风险 2. 用户能有一段熟悉新系统的时间 3. 可以验证用户指南和使用手册之类的文档 4. 能够以准生产模式对新系统进行全负荷测试可以用测试结果验证性能指标 n 单元测试的重点1. 模块测试2. 局部数据结构 3. 重要的执行通路 4. 出错处理通路 5. 边界条件 n 集成测试是测试和组装软件的系统化技术其主要目标是发现与接口有关的问题。其特点是可能发生接口问题 n 集成测试的方法1. 非渐增式测试方法先分别测试每个模块再将所有的模块结合 在一起 2. 渐增式测试方法一次增加进来一个待测试的模块自底向上自顶向下 n 自顶向下集成的优点不需要测试驱动程序能够在测试阶段的早期实现并验证程序的主要功能而且能在早期发现上层模块的接口错误 n 自顶向下集成的缺点需要存根程序可能遇到与此相联系的测试困难底层关键模块中的错误发现较晚而且用这种方法在早期不能充分展开人力 n 回归测试重新执行已经做过的测试的某个子集以保证增加进的新的模块没有带来非预期的副作用 n 回归测试的内容1.检验软件功能的代表性测试用例 2. 专门针对可能受影响的软件功能的附加测试 3. 针对被修改过的软件成分的测试 n 确认与验证的区别验证指的是保证软件正确的实现了某个特定要求的一系列活动确认指的是为了保证软件确实满足了用户需求而进行的一系列活动 n 软件有效性的定义如果软件的功能和性能如同用户所合理期待的那样软件就是有效的 n 确认测试的内容1.复查软件配置 2. 检验使用手册的完整性与正确性 3. 检测软件是否与需求一致 4. 保证软件能满足所有功能要求 5. 文档资料是准确完整的 6. 软件能满足其他预定的要求安全性、可移植性、兼容性。可维护性 n 确认测试基本使用黑盒测试法 n 软件配置复查的目的保证软件配置的所有成分都齐全质量符合要求文档与程序完全一致具有完成软件维护所必须的细节而且已经编好目录 n 白盒测试技术逻辑覆盖技术与控制结构测试技术基本路径测试、条件测试和循环测试 n 逻辑覆盖技术1. 语句覆盖。每个语句应该执行一次 2 判定覆盖。不仅每个语句至少执行一次而且每个判定的每种可能结 果也应该至少执行一次 3 条件覆盖。不仅每个语句至少执行一次判定表达中每个条件都取到各种可能得结果 4 判定/条件覆盖。同时满足两种覆盖 5 条件组合覆盖。每个判定表达式中条件的各种可能组合都至少出现一次 6 点覆盖 7 边覆盖 8 路径覆盖 n 基本路径测试的步骤1.根据过程结构画出相应的流图 2.计算流图的环形复杂度 3.确定线性独立路径的基本集合 4.设计可强制执行基本集合中的每条路径的测试用例 n 条件测试错误的类型:1.布尔算符错 2.布尔变量错 3.布尔括弧错 4.关系算符错 5.算数表达式错 n 条件测试策略的优点1.容易度量条件的测试覆盖率 2.程序内条件的测试覆盖率可指导附加测试的设计 n 条件测试的目的不仅是检验程序条件中的错误而且是检验程序中的其他错误 n 循环测试的三种办法1. 简单循环 2. 嵌套循环 3. 串接循环 n 黑盒测试法把程序看成一个黑盒子完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试它只检查程序功能是否能按照规格说明书的规定正常使用程序是否能适当地接收输入数据产生正确的输出信息并且保持外部信息(如数据库或文件)的完整性。 n 黑盒测试主要用于测试的后期 白盒测试主要用于早期 n 黑盒测试力图发现下述类型的错误 ①功能不正确或遗漏了功能 ②界面错误 ③数据结构错误或外部数据库访问错误 ④性能错误 ⑤初始化和终止错误。 n 黑盒测试法技术1.等价划分 2. 边界值分析 3.错误推测 n 等价类划分等价类划分方法把所有可能的输入数据即程序的输入域划分成若干部分然后从每一部分中选取少数有代表性的数据做为测试用例。 n 等价类划分先要划分等价类接下来一次测试有效等价类与无效等价类 n 错误推测法的基本想法是列举出程序中所有可能有的错误和容易发生错误的特殊情况根据它们选择测试方案。 n 调试调试是在测试发现错误之后排除错误的过程 n 调试途径1. 蛮干法 2. 回溯法 3. 原因排除法 n 软件可靠性软件可靠性是指程序在给定的时间间隔内按照规格说明书的规定成功的运行的概率 n 软件可用性程序在给定的时间点按照规格说明书的规定成功的运行的概率 n 可靠性与可用性的区别可靠性是指一段时间间隔内程序没有失效可用性意味着这段时间内程序正确运行 n MYTTF 平均无故障时间 Et 测试之前程序中错误总量 Ir程序长度 Ec x时间内改正的错误 n MTTF 1/K*(Et/Ir-Ec/Ir) **是减号 第八章 ü 软件维护的基本任务作用是保证软件在一个相当长的时期能够正常运行 ü 软件维护在软件已经交付使用之后为了改正错误或者满足新的需要而修改软件的过程 ü 软件维护的本质修改和压缩了的软件定义和开发过程而且事实上远在提出一项维护要求之前与软件维护有关的工作就已经开始了 ü 软件维护的分类1. 改正性维护。诊断和改正错误 2. 适应性维护。为了和变化了的环境适当的配合而进行的修改软件 的活动 3. 完善性维护。增加新功能或修改已有功能 4. 预防性维护。给未来的改进奠定良好的基础 ü 软件维护的特点1. 结构化维护与非结构化维护差别巨大 2. 维护的代价高昂 3. 维护的问题很多 ü 维护过程的问题1. 理解别人写的程序通常非常困难 2. 需要维护的软件往往没有合格的文档或者文档资料显著不足 3. 当要求对软件进行维护时不能指望由开发人员给人们自习说明软件 4. 绝大多数软件在设计时没有考虑将来的修改 5. 软件维护不是一项吸引人的工作 ü 软件维护的过程1. 维护组织 2. 维护报告 3. 维护的事务流 4. 保存维护记录 5. 评价维护活动 ü 决定软件可维护性的因素1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性 ü 提高可维护行的方法建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 ü 软件文档分为系统文档与用户文档 ü 软件文档的要求1. 必须描述如何使用这个系统 2. 必须描述怎样安装和管理这个系统 3. 必须描述系统需求和设计 4. 必须描述系统的实现与测试以便使系统成为可维护的 ü 用户文档五方面内容1. 功能描述 2. 安装文档 3. 使用手册 4. 参考手册 5. 操作员指南 ü 开发与维护的关系 许多软件的维护十分困难原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法忽视程序设计风格等。 ü 软件维护与软件工程的关系软件维护时软件工程的最后一个阶段软件工程的主要目的就是提高软件的可维护性减少软件维护所需要的工作量降低软件系统的成本。软件维护决定了未来软件工程的可靠性与可维护性。 ü 在软件开发过程中应该采取哪些措施来提高软件的可维护性 在每个阶段结束前的技术复审和管理复查中应该着重对可维护性进行复审应该对将来要改进的部分和可能要改的部分加以注意指明应该讨论软件的可移植性问题考虑可能影响软件维护的系统界面。在设计和编码过程中应该尽量使用可重用的软件构件每个测试步骤都可以暗示在软件正式交付使用之前程序中可能需要做预防性维护的部分。在完成每项维护工作之后都应该对软件维护本身仔细认真的复审。 ü 需求分析的目的/意义/必要性为了开发出真正满足用户需求的软件产品首先必须知道用户的需求。对软件需求的深入理解是软件开发工作获得成功的前提条件不论我们把设计和编码工作做得如何出色不能真正满足用户需求的程序只会令用户失望给开发者带来烦恼。 ü 需求分析的任务确定对系统的综合要求 1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求 分析系统的数据要求分析系统的数据结构图形工具描 述数据结构[层次方框图和Warnier图]数据结构规范化 导出系统的逻辑模型数据流图实体联系图状态转换 图数据字典和主要的处理算法描述 修正系统开发计划 ü 与用户沟通获取真实需求的的方式1. 访谈 2. 面向数据流自顶向下求精 3. 简易的应用规格说明技术 4. 快速建立软件原型 ü 需求分许是软件定义的最后一个阶段他的主要任务时准确回答“系统必须做什么”这个问题不是确定系统怎样完成他的工作 ü 需求分析结束之前应出具软件需求规格说明书书面形式准确描述软件的需求转载于:https://www.cnblogs.com/Flower-Z/p/9026583.html
