[关闭]
@laofang 2016-03-15T11:27:40.000000Z 字数 4331 阅读 1726

软件工程复习

软工

软件危机:

定义: 在计算机软件的开发和维护中所遇到的一系列严重问题

典型表现:

  1. 开发成本和进度的估计常常很不准确
  2. 用户对已完成的软件系统很不满意
  3. 软件质量不可靠
  4. 软件常常是不可维护的
  5. 软件成本比例逐年上升
  6. 软件产品供不应求

原因:

  1. 软件规模加大, 复杂性提高, 性能增强
  2. 软件是逻辑产品:缺乏可见性,不会"用坏",软件的产品成本主要体现在软件的开发和维护上
  3. 缺乏系统的开发 维护大型软件项目的技术手段和管理方法
  4. 用户和软甲开发人员的理解鸿沟

消除途径:

  1. 消除"软件就是程序"的错误观念
  2. 软件是程序 数据 及相关文档的完整集合. 文档是开发,使用和维护程序所需要的图文资料

软件开发是工程项目

  1. 成功的软件开发技术和方法
  2. 软件工具和软件工程的支撑环境

软件工程

定义:

  软件工程师指指导计算机开发和维护的一门工程学科, 采用工程学的概念, 原理, 技术和方法来开发和维护软件, 把经过时间考验而证明正确的管理技术和当前能够得到的做好的技术方法结合起来以经济的开发出高质量的软件并有效的维护它

本质特性:

  软件工程的中心课题是控制复杂性
  和谐地合作是开发软件的关键

软件工程方法学:

  1. 两个方面: 技术 管理

  2. 三个要素

    • 软件工具
    • 软件方法
    • 软件过程

  3. 软件生命周期:
    软件生命周期就是软件产品或系统一系列相关活动的全周期

    • 三大阶段:

      • 软件定义
        问题定义
        可行性研究
        需求分析
      • 软件开发
        总体设计
        详细设计
        编码和单元测试
        综合测试
      • 软件维护

软件生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序, 因此也称为过程模型

典型的过程模型:

需求分析

任务:

    1. 准确地回答"系统必须做什么"
    2. 分析 软件需求和书写软件需求规格说明书

软件需求:

  • 用户解决问题或达到目标所需要的条件或者能力
  • 系统或系统部件要满足合同,标准,规范或者其他正式文档所需具有的条件或能力
  • 反映上述两个定义中所描述的条件或能力的文档说明

  1. 需求层次:

    • 业务需求
    • 用户需求
    • 功能和非功能需求

  2. 具体任务:

    • 确定对系统的综合需求
    • 分析系统的数据需求
    • 导出系统的逻辑模型
    • 修正系统的开发计划

  3. 数据流图:

    • 口: 数据原点/数据终点
    • →: 数据流
    • |二: 数据存储
    • O: 加工/处理
  4. 状态图:
    • 通过描绘系统的状态及引起的状态转换事件, 来表示系统的行为

总体设计:

任务:

    1. 概括的说, 系统应该如何实现
    2. 系统划分
        即确定组成系统的程序, 文件, 数据库, 人工过程和文档等
    3. 设计软件的结构:
        即确定每个程序是由哪些模块组成,以及这些模块之间的关系

设计原理:

    模块化
        c(p1 + p2) > c(p1) + c(p2)
        E(p1 + p2) > E(p1) + E(p2)
    抽象:
        抽象就是抽出事务的本质特征而暂时不考虑他们的细节
    逐步求精:
        为了能集中精力解决主要问题而尽量推迟对问题细节的考虑
    信息隐藏和局部化
        信息隐藏原理:
            应该这样设计和确定模块, 使得一个模块内包含的信息对于不需要这些信息的模块来说, 是不能访问的
        局部化:
            把一些关系密切的软件元素物理地放得彼此靠近

模块独立

        每一个模块完成一个相对独立的子功能, 并且与其他模块间的接口简单
        模块独立性的衡量标准
            模块内聚
                偶然性内聚
                逻辑性内聚
                时间性内聚
                过程性内聚
                通信性内聚
                顺序内聚
                功能性内聚
                信息性内聚
            模块耦合
                内容耦合
                共用耦合
                控制耦合
                印记耦合
                数据耦合

          设计师力争做到低耦合. 应该采取的设计原则是: 尽量使用数据耦合, 少用控制耦合和特征耦合, 限制共用耦合的范围, 完全不用内容耦合.

          设计时力争做到高内聚, 并且能够辨认出低内聚的模块, 空过修改设计提高模块的内聚程度

    启发规则:
        改进软件结构, 提高模块第理性
        模块规模应适中
        深度, 宽度, 扇出 扇入 都应适当
        模块作用域应该在控制域之内
            作用域:
                受该模块内一个判定影响的所有模块的集合
            控制域:
                模块本身及所有直接或者简介从属于他的模块的计划
        力争降低模块接口的复杂程度
        设计单入口单出口的模块
        模块功能应该可以预测

    结构图:
        描述软件系统的模块层次结构, 清楚的反映出程序中各模块之间的  调用关系  和 数据传递
    面向数据流的设计方法:
        两种思想: dfd -> 结构图
        两种信息流类型: 变换流, 事务流
        变换流到软件结构图的转换

详细设计

任务:
    不是具体的编写程序, 而是设计程序的蓝图
结构程序设计
    结构化定理:
        任何单入口单出口的程序都可以由 顺序  选择 和  循环 三种基本结构实现
    过程设计的工具(重点是画图)
        程序流程图
        盒图
        pad图
        判定表

实现

编码风格
    编码风格的作用就是使代码容易解读
    风格良好的代码更容易月的和理解, 错误更少
        使用一致和有意义的标识符名
        用缩进显示程序结构
        用加括号的方式排除二义性
        避免大量使用循环嵌套和条件嵌套
        当心运算符的副作用
        吧数定义成常量
        利用sizeof()计算对象大小
        清晰的代码, 而非最巧妙的代码
        程序的注释:
            序言性注释和功能性注释
            对一段程序进行注释而不是每个语句
        使用数据结束标记eof, bof 不要指定数据的数目来判断文件的结束

测试和调试:

  测试的目的即使在软件投入生产性运行之前, 尽可能多地发现软件中的错误
    调试的目的是诊断并改正错误, 由程序员完成

测试:

  • 对软件规格说明,设计和编码的最后复审
  • 开发总工作量的40%以上
  • 测试是为了发现程序中的错误而执行程序的过程
  • 好的测试方案是极可能发现迄今为止没有发现的错误的测试方案
  • 成功的测试是发现了迄今为止尚未发现的 错误的测试
  • 测试只能查出程序中的错误, 而不能证明程序中没有错误
  • pareto原理:
    80%的错误是20%的模块造成的
  • 从小规模测试逐步到大规模测试
  • 穷举测试是不可能的
  • 为了达到最佳测试效果, 应该有独立的第三方从事测试工作

测试方法:

  • 白盒测试 (结构测试 逻辑驱动测试)
  • 黑盒测试 (功能测试 数据驱动测试)

测试步骤:

集成测试方法:

  1. 非渐增式:

    先分别测试每个模块,再把所有的模块按设计要求放在一起结合成所要求的程序 .
    先进行单元测试, 再进行集成测试

  2. 渐增式:

    • 自顶向下

          优点
        错误隔离
        较早发现主要设计错误
    缺点
        可复用模块得不到充分测试

    • 自底向上

          优点:
        错误隔离
        可复用模块得到充分的测试
    错误:
        主要设计错误发现迟

    • 三明治式

          优点:
        错误隔离
        较早发现主要设计错误, 可复用模块得到充分测试
    缺点:
        没有缺点

白盒测试技术:逻辑覆盖

黑盒测试技术:

等价划分

        1. 把程序的输入划分成若干个数据类, 每类中的一个典型值在测试中的作业与这一类中所有其他值的作用相同, 据此导出测试用例
        2. 设计测试用例:设计一个新的测试方案以尽可能覆盖尚未被覆盖的等价类, 重复这一步骤知道所有有效等价类都被覆盖为止
        3. 设计一个新的测试方案,使他覆盖一个且只有一个尚未被覆盖的无效等价类, 重复这一步骤直到所有无效等价类都被覆盖为止

维护

  • 所谓软件维护就是在软件已经交付使用之后, 为了改正错误或满足新的需要而修改软件的过程, 保证软件在一个相当长的时间能够正常运行
  • 时间占比: 60%以上, 这个百分比还在持续上升.

维护类型:

软件的可维护性:

    维护人员理解改正改动或改进这个软件的难易程度
    提高可维护性是支配软件工程方法学所有步骤的关键目标
    决定软件可维护性的因素
        可理解性
        可修改行
        可测试性
        可移植性
        可重用性

面向对象方法学

面向对象方法学

面向对象建模:

面向对象设计:

面向对象设计的任务:

    系统设计:
        确定实现系统的策略和目标系统的高层结构
    对象设计:
        确定解空间中的类, 关联, 接口形式及实现服务的算法

面向对象设计的准则:

    模块化
    抽象
    信息隐藏
    耦合
    内聚

重用:
    重用有两方面的含义:
        1. 尽量使用自己已有的类
        2. 如果确实需要创建新的类,则在设计这些类的协议时,应该考虑将来的可重用性
添加新批注
在作者公开此批注前，只有你和作者可见。
回复批注