软件工程知识要点

软件工程要点•软件–计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。•软件的特征–软件是一种逻辑产品，而不是物理产品，具有抽象性。没磨损，老化问题–软件产品的成本主要体现在软件的开发和维护上，制造几乎没有成本–大多数软件都是从头开发的。•软件危机–软件代价高–开发过程难以控制–软件工作量估计困难–软件质量底–软件修改、维护困难•软件工程–应用计算机科学、数学及管理科学等原理开发软件的过程。它借鉴传统工程的原则、方法，以提高质量、降低成本为目的。•软件工程层次–质量焦点：软件工程必须以有组织的质量保证为基础–过程：软件过程是开发和维护软件及其相关产品（项目计划、设计文件、编程代码、测试、用户手册）的一系列活动、方法、实践和变换。–方法：软件工程方法为软件开发提供“如何做”的技术–工具：软件工具为过程和方法提供自动的或半自动的支持。这些软件工具被集成起来，建立起一个支持软件开发的系统，称之为计算机辅助软件工程（CASE，ComputerAidedSoftwareEngineering）。软件工程层次•软件生命周期–软件产品或系统一系列相关活动的全周期。•软件生命周期分成以下几个阶段–软件定义•问题定义、可行性研究、需求分析–软件开发•总体设计、详细设计、编码和单元测试、综合测试–软件维护•软件过程模型–又称软件工程开发模型，或称软件生命期模型，是软件开发的全部过程、资源、活动和任务的结构框架。–典型软件过程模型•瀑布模型(WaterfallModel）•快速原型模型•增量模型•瀑布模型(WaterfallModel）问题定义需求分析总体设计详细设计编码实现维护让位•瀑布模型各阶段的任务–问题定义：确定用户要求解决的性质、工程的目标和规模。对要开发的软件进行可行性研究（经济可行性、技术可行性、法律可行性、不同的方案），确定软件元素的作用范围，并对软件进行成本估算，制定进度安排，最后提交软件计划。–软件需求分析：最根本的任务是确定为了满足用户需求系统必须“做什么”。即确定系统必须具有的功能和性能，系统要求的运行环境，并预测系统发展的前景。提交软件需求规格说明书。–总体设计：总体设计的基本任务是确定模块分解、各模块功能和模块间接口，设计全局数据结构。–详细设计：确定各模块的实现细节和局部数据结构。–编码：把软件设计转换成计算机可以接受的程序代码。–测试：发现软件错误。–维护：使用期间对软件进行补充、修改和增加工作。•矫正性维护：识别与矫正软件中的错误•适应性维护：使软件适应新的环境和数据需求的改变•完善性维护：扩充软件功能或改善软件性能•预防性维护：为便于将来的维护和性能提高所进行的预防性措施•瀑布模型的特点–阶段间的顺序性和依赖性–文档驱动•瀑布模型存在的问题–依赖于早期进行的唯一次需求调查，不能适应需求变化–阶段的划分完全固定，阶段间产生大量的文档，极大地增加了工作量；–开发是线性的，用户只有等到整个过程的末期才能见到开发成果，增加了开发的风险；–早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。•快速原型模型–对用户所提出的软件产品的部分实现，是真实系统的一个模型–使用原型的目的•明确并完善需求•探索设计方案•发展为最终的产品原型–抛弃型原型•不作为最终交付产品的一部分；•用来检验讨论中的需求或方案是否确实是用户需要。–进化型原型•将作为最终产品的一部分；•用于检验和解释问题。•增量模型(IncrementalModel）–软件被作为一系列的增量构件来设计、实现、集成和测试；–每一个线性序列产生软件的一个可发布的增量–第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。•传统方法学与面向对象方法学–结构化方法•采用“抽象”和“分解”两个基本手段。•属于功能/数据方法，即将系统的功能和涉及的数据或多或少地分开来处理–面向对象建模方法•面向对象方法学出现于20世纪80年代中后期，并迅速成为20世纪90年代的主流开发方法。•以客观世界中实体为基础，将客观实体的属性与操作封装成对象，对象之间通过传递消息互相联系，以模拟现实中不同事物彼此之间的联系。•采用“封装”、“分类”和“继承”三个基本原则。•成熟度等级(MaturityLevels)：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。•需求定义–用户解决问题或达到目标所需要的条件或能力（Capability）–系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力–反映上述两个定义中所描述的条件或能力的文档说需求分析需求描述原型及测试文档化及验证尚未掌握所有的需求描述方法不得当功能不合实际需求的获取与分析需求定义与规格说明•确定需求的过程•需求的层次与种类–业务需求：反映了组织机构或客户对系统和产品高层次的目标要求。体现在项目前景与范围文档中。–用户需求：描述了用户使用软件产品所必须完成的任务。体现在用例文档或方案脚本中。–功能需求和非功能需求：定义了开发人员必须实现的软件功能，体现在需求文档中。•功能需求：物理环境、接口、用户、功能、数据、资源、安全性•非功能需求：可移植性、可靠性、效率或性能、易用性、可重用性、安全性•需求的验证–审查需求文档–依据需求编写测试用例–编写用户手册–确定合格的标准•好的需求应具有的特性–正确性：与用户对软件产品的期望一致–无二义性–完整性–一致性–可行性–可验证性–可跟踪性–非计算机人员能够理解•需求描述–静态描述方法•间接引用、关系递归、公理化定义、语言描述、数据抽象–动态描述方法•决策表、函数描述和状态转移图、Petri网–面向对象的描述方法–Warnier图–数据流图•需求文档–需求定义文档（RequirementsDefinition）•从用户的角度出发，将用户希望系统实现的功能作一个汇总，通常由用户和开发者共同撰写•主要读者为用户–需求规格说明(RequirementsSpecification)•又称功能规格说明、需求协议和系统规格说明•精确地阐述了一个软件系统必须提供的功能和性能以及它所要考虑的限制条件•由系统分析师撰写•主要读者为系统设计与开发人员•需求管理–变更控制–版本控制–需求跟踪–需求状态•面向对象=对象+类+继承+消息通信•类:一组具有相同属性和相同行为的对象的集合•消息：一个对象与另一个对象的通信单元，是要求某个对象执行某个操作的规格说明。•继承：子类自动地共享父类（超类）的属性和方法•OO系统设计任务–系统分解成子系统–识别问题中固有的并发性–将子系统分配给处理器和任务–选择数据存储管理方法–处理对全局资源的访问–选择软件控制机制–处理边界条件–设置平衡的优先级•UML–UML是一种可视化建模语言–UML不是一种开发方法，不局限于特定开发过程•用例（Use-Case）是系统的一种行为，它为执行者产生一定的价值结果。用例描述执行者想要系统完成的事情。用例应该是一个完整的任务。•参与者(Actor)是同系统交互的所有事物，如人、其它软件、数据存储、硬件设备或网络。每个执行者定义一种特定角色。•用例图：表示一组用例、参与者及它们之间的关系，从用户的角度出发对系统建模•设计内容–数据设计：信息模型、软件数据结构–体系结构设计：定义软件部件间的关系–接口设计：软件内部、外部及与人之间的通信–过程设计：软件组件的过程性描述•分解与模块化的基本原理C(P1+P2)C(P1)+C(P2)E(P1+P2)E(P1)+E(P2)C为问题的复杂度，E为解题需要的工作量•耦合1.内容耦合contentcoupling2.公共耦合commoncoupling3.控制耦合controlcoupling4.特征耦合stampcoupling5.数据耦合datacoupling6.非直接耦合nodirectcoupling•内聚cohesion–功能性内聚：模块中各个组成部分构成一个整体并共同完成一个单一的功能–顺序性内聚：模块中的各个部分都与同一个功能密切相关，并且必须按照先后顺序执行(通常前一个部分的输出数据就是后一个部分的输入数据)–通讯性内聚：模块中的各个部分使用同一个输入数据或产生同一个输出数据–过程性内聚：模块中的各个部分相关，并且必须按特定的次序执行–时间性内聚：模块包含了在同一时间段中执行的多个任务–逻辑性内聚：模块可实现多个逻辑上相同或相似的一类功能–偶然性内聚：模块由多个完成不同任务的语句段组成，各语句段之间的联系十分松散或根本没有任何联系•程序设计风格–程序设计风格的作用就是使代码容易读–风格良好的代码更容易阅读和理解，其中的错误也更少•命名–匈牙利标记法：[Prefix]-BaseTag-Name•用缩格显示程序结构•用加括号的方式排除二义性•要清晰：清晰的代码，而非最巧妙的代码•当心运算符的副作用•把数定义称常量•利用sizeof()计算对象的大小•程序注释•缺陷(Fault)：是开发人员所看到的软件系统的内部问题。•失效（failure）：是用户所看到的软件系统所表现出来的外部问题。•软件测试是为了发现缺陷而执行程序的过程•测试是为了证明程序中有错误，而不是证明程序中无错误•一个好的测试用例指的是它可能发现至今尚未发现的缺陷•一次成功的测试指的是发现了新的软件缺陷的测试•测试类型–根据是否需要了解软件内部的结构分•黑盒测试（功能测试或数据驱动测试）•白盒测试（结构测试或逻辑驱动测试）–根据是否需要运行被测试的程序分为：•静态测试：不实际运行被测试的程序，如：代码走查，Fagan检查•动态测试：运行被测试的软件•功能测试，即黑盒测试–根据软件的需求定义或功能规约对软件进行测试–检查软件的输入和输出数据是否满足需求定义的要求–方法：将软件的输入空间分解成一系列子域，使得软件在子域内的行为是“等价”的•黑盒法分类–子域分解–边界值分析–因果图，决策表•软件测试阶段–单元测试–集成测试•驱动模块、桩模块•自底向上集成•自顶向下集成•三明治集成–系统测试–验收测试–安装测试