软件工程知识要点

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