学堂在线_软件工程 专业基础知识点 笔记

• 基本概念：

  • 软件工程诞生：1968年北大西洋公约组织召开国际会议，提出软件工程的概念和术语。
  • 软件的定义：程序 + 数据 + 文档。
  • 软件的本质特性：复杂性、一致性、可变性、不可见性。
  • 软件工程定义：将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即将工程化应用于软件，及对上述方法的研究。
  • 软件工程的基本要素：过程、方法、工具；
  • 软件开发的基本策略：软件复用（已有构建组装）、分而治之（复杂问题分解）、逐步演进（增量或迭代）、优化折中（整体质量最优）；
  • 软件质量：用户角度，关注功能质量；开发角度，关注结构质量；投资者角度，关注过程质量；
  • 软件过程：包括问题定义、需求开发、软件设计、软件构造、软件测试，软件项目管理和软件配置管理。

• 常见软件过程模型：瀑布、原型化、迭代式（有分块的增加增量模型和逐步完善的迭代模型）、可转换（适用于对安全性和可靠性要求极高的系统）等四种模型。

• 敏捷开发方法中最具影响力的两种方法是：极限编程和Scrum小周期迭代。

• 编程规范：

  • 注释，好的注释解释为什么，而不是是什么；注释不是代码的描述；修改代码同时修改周边注释。
  • 命名，好的名字见文知义；尽量编写自文档化代码；类名为驼峰风格（逐个字母连接且首字母大写），变量名为下划线风格（小写字母用下划线连接）。
  • 语句，应该删繁就简，避免奇技淫巧。

• 高质量的设计：模块化设计、面向抽象编程、错误与异常处理。

• 代码审查（code review）：是确认方案设计与代码实现的质量保证机制，通过阅读代码来检查源代码与编码规范的符合性及代码质量。

• 代码优化：是代码的等价变换，优化前后结果相同，效率（时间或空间）提升。优化步骤：找瓶颈（如用profile找出python代码中各函数的执行时间），先全局后局部，先数据结构和算法后代码。

• 单元测试（Unit testing）是对软件中的最小可测试单元进行的检查和验证。指标，单元测试的测试通过率要求100%，代码覆盖率，用来度量测试完整性，了解测试是否充分及弱点。

  • 黑盒测试：是功能测试，不考虑内部结构和逻辑，只按需求说明，验证功能是否实现。
  • 白盒测试：是结构测试，根据程序内部逻辑，设计测试用例，对程序的逻辑路径也进行测试。

• 开发团队的组织模式：民主式结构（团队成员平等协商）、主程序员式结构（以主程序员为主分工配合）、矩阵式结构（管理与技术分离）。

  Brooks法则：向一个进度延迟的软件项目中增加人员可能会使其进度更加推迟。

• 项目沟通之前需要明确：与沟通的对象是什么关系类型？需要什么类型的信息？详尽程度和频率如何？沟通的目标是什么？采用哪种方式沟通为宜？

• 项目估算：对时间和成本进行预算和估计的过程，有6种方法：专家判断、参数估计；功能点估计、用例点估算；结构性成本模型、机器学习方法。

• Scrum框架中

  • 角色：product Owner（定义产品需求、发布计划、产品收益、定义需求优先级）、Scrum Manager(直接管理项目、组织每日站立会议、引导促进团队协作)、team（合作完成每次的Sprint开发工作）；

  自组织团队是敏捷软件开发的基本概念，即团队被授权自己管理他们的工作过程和进度，并且决定如何完成工作。每日站立会议主题是三个问题：上次例会后完成了什么？遇到了什么困难？下次例会前计划做什么？

  • 制品：product backlog（从客户价值角度理解的产品功能列表）、Sprint backlog（从开发技术角度理解的迭代开发任务）、working software（是可交付的软件产品）、burndown charts（展示剩余工作量与时间的关系图）；
  • 活动：Sprint planning / daily scrum Meeting / Sprint review / Sprint retrospective。

• 用户故事与估算

  • 用户故事：(User Stroy)是从用户角度对功能的简要描述。有独立性、可协商、有价值、可估算、短小可测试的特点。
  • 故事点：是一个相对度量单位，用以结合开发者水平估计开发任务的耗时程度。（理想时间，是一个绝对度量单位，是剔除外围活动后的所需时间，通常为一天有效工作时间的60%-80%）。
  • 估算原则：开发团队一起估算，owner / manager 不参与实际估算。（敏捷估算扑克方法：分牌—>用户故事讲解—>估算—>争论与讨论—>共识）

• 软件配置管理：对软件开发全周期进行标识、组织和控制修改的技术， 目的是为了使错误达到最小并有效地提高生产率。使软件开发过程完整、一致、可追溯。

  • 2种版本控制模式：独占工作模式（编辑时文件被锁定）、并行工作模式（同时复制，后提交者需要先checkout）
  • 常用工具：SVN / Git；

• 需求工程师：

  • 需求管理的三个任务：学习以获取需求、剪枝以需求优选、文档化即撰写需求规格说明书。
  • 好的需求描述：
    • 单个需求项：concise / correct / Non-ambiguous / feasible / verifiable；
    • 整个需求集合：realistic / concise / complete / consistent。
  • 不好的需求描述：含糊、错误、不完整、矛盾或不一致、无法测试。
  • 需求分类：
    • 产品需求：功能性需求、非功能性需求（服务质量、依从性 { 描述软件对国家法律、国际公约、文化政治习俗、标准等环境约束的满足程度 } 、体系结构约束、设计开发约束）。
    • 抽象层次详细程度：业务需求（业务陈述，系统的业务目标）、用户需求（影响用户接受程度的需求）、系统需求（从用户角度描述功能）、软件需求（软件部分的需求，帮助实现系统需求）。
  • 需求规格说明（software requirements specification）： 清楚地描述软件在什么情况下，需要做什么，不能做什么；以输入/输出及之间的转换方式来描述功能性需求；描述经干系人磋商达成共识的非功能性需求。一般要参考模板、具有一定法律效力，可作为后续软件评估的依据和变更的基准。

• 用例建模(Use Case Modelling)：情景驱动的建模方法，用例定义一个参与者要用到的系统功能、行为序列、交互活动，是从用户角度出发，完整的实现特定用户价值的事件流。

  • 构建用例模型的步骤
  • 寻找用例的方法
  • 用例建模过程
  • 用例建模工具：UML

• 面向对象分析(object-oriented analysis, OOA)：

  • 五个核心概念：对象、属性、结构、服务和主题。
  • 对象建模五大有力武器或原则：抽象（找出共性、忽略不相关细节）、分解（区分整体与部分关系）、多视角映射、模块化、模式。
  • 识别类的方法：使用CRC(class responsibility collaboration)分析法：根据类的职责确定类。分为边界类、控制类、实体类。
  • 抽象的接口：让用户知道关于类的内部实现细节越少越好。
  • 确定对象行为的原则：开闭原则（软件实体在扩展性方面开放、在更改性方面是封闭的）、LSP替换原则（子类可以替换父类出现在父类出现的任意地方）、依赖倒置原则（依赖关系应该尽量依赖接口，而不是具体的类）、接口分离原则（采用多个和特定客户类有关的接口，而不是采用通用接口）。

• 顺序图-交互行为建模：

  • 顺序图：用来刻画系统实现某个功能的必要步骤；
  • 消息：用于描述对象间的交互操作和值传递过程；
  • 顺序图的构造

<---------------------------------------------------------------------------------------------------------------------->

当软件系统的规模和复杂性不断增加，对系统 的全局结构设计和规划变得比算法的选择和数据结构的设计，更为重要。

• 软件体系结构 = 构件 + 连接件 + 约束；
  • 构件：可复用的软件结构单元，表示系统中主要的计算要素和数据存储。
  • 连接件：连接是构件之间建立和维护行为关联与信息的途径， 实现构件之间交互连接的专用构件，一般构件是软件功能设计和实现的载体。
  • 建立体系结构的目标：可重用、可扩展（易增功能）、可变化性（易变更功能）、简单化（复杂问题分块化简）、有效性（体现早期的设计决策）。
• 软件设计原则：抽象（关注解决事物问题的部分，忽略无关部分的一种思考方法）、封装（各功能单元由外部可见接口描述）、模块化（在逻辑上和物理上将整个系统分解成多个更小部分）、层次化（分解为对等的模块单元）、复用（利用已有）。
  • 单元接口设计，应尽量降低对环境的假设和要求。
  • 模块化的模块分解原则：高内聚、低耦合。
  • 复用包括：源代码复用、软件体系结构复用、框架复用、设计模式。
• 软件体系结构风格：描述特定系统组织方式的惯用范例，强调了软件系统中通用的组织结构。有以下几种：
  • 主程序-子程序：从功能的观点设计系统，通过逐步分解细化，形成整个系统的体系结构
  • 面向对象风格：系统被看做是对象的集合，每个对象有自己的功能集合，经封装再交互。
  • 管道-过滤器风格：把系统任务分成若干连续的处理步骤，由通过系统的数据流连接，一个步骤的输出是下一个步骤的输入。如：媒体播放器。
  • 以数据为中心风格（仓库体系结构）：适用于数据由一个模块产生，多个模块使用的情况。eg：程序设计语言编译器、基于数据库的系统结构
  • 层次结构：如安卓系统、网络分层。
  • 客户机/服务器（C/S）体系结构：服务器负责为其他客户机提供服务，客户机作为子系统负责与用户交互。
  • 两层C/S结构：
    • 胖客户机模型：服务器只负责数据的管理，客户机实现应用逻辑和用户的交互。
    • 瘦客户端：客户端具有很少或没有业务逻辑。
  • 三层C/S结构：表示层（包括所有与客户机交互的边界对象）、功能层（实现业务逻辑）、数据层（实现对数据库的存储、查询和更新）。B/S结构，是三层c/s的一种实现方式。
  • 集群结构：集群内服务器内容一致，或集群服务器内容之和构成完整系统功能/数据。
  • MVC结构：将数据模型、业务逻辑、用户界面分别放在独立构件中，这样用户界面的修改不会对数据模型/业务逻辑造成太大影响。
  • 事件风格：将应用看成一个构建集合，每个构建直至发生对它有影响的事件时才使用。
• 软件体系结构风格的选择：基于经验，考虑复合、技术因素、质量因素等。
• 软件设计过程：
  • 系统总体设计 ：在需求分析基础上定义系统的设计目标，划分子模块，建立体系结构，选择合适的设计策略；
• 数据库选择策略：怎么存？怎么增删改查？操作是否安全？可用性（指故障恢复）？常用数据库特点：
  • Mysql ：开源型关系数据库，大量第三方插件，支持快速复杂查询、较高安全性。查询并发量2000；
  • mongodb：模式自由，支持海量数据的查询和插入，修改方便；支持完全索引；大空间以索引，高级别安全性无法保证。查询并发量5000；
  • Redis：内存访问高效，也能持久化存储，字典模式存储；不适合安全性高的情景。
• 软件设计 = 编码设计 + 交互设计（UI）基于人机交互的界面设计，更关注可用性。
  • GUI设计原则：可视化（分组、排序、对齐、装饰、留白）、一致性（有相似的操作、相似任务用相似的元素、目的是让界面更好去学习和使用）、直接映射（控制、动作、结果建立关联）、有效反馈。
  • KLM效率模型：
  • Fitts定律：
• 软件测试（以改进software过程）：正向思维，验证软件正常工作（check functions）；逆向思维，假定软件有缺陷（find error）。
  • 测试局限性：不彻底、不完备、间接性。——>测试应尽早介入

  缺陷的集群性：软件错误具有聚集性，对存在错误的部分应重点测试。
  杀虫剂悖论：用同样的测试用例多次重复测试，最后将不能发现新的缺陷。——>要定期修改测试用例。

  • 软件测试类型：
    • 测试对象角度：单元测试、集成测试、系统测试、性能测试、验收测试、安装测试
    • 测试技术角度：黑盒测试（功能）、白盒测试（结构）
    • 程序执行角度：静态、动态测试
    • 人工干预角度：手工测试、自动化测试。
  • 软件测试计划：why、what、when、where、who、how；
    • 缺陷报告内容：基本描述（一句话描述清楚问题）、详细描述（基本环境、异常发生操作步骤、截图、日志或出错信息、测试人员角度的简单分析、被测软件基本信息、修改优先级、提交日期提交人等）、相关附件。
  • web应用功能测试：网页测试（内容、链接、表单、cookies）、网站测试（设计语言、数据库等测试、特定功能、兼容性）。
  • 软件性能测试：及时性、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性。
  • 性能测试策略：应用在客户端性能的测试（虚拟并发用户数渐增）、应用在网络性能的测试（网络带宽、延时、负载、TCP端口变化下的响应时间）、应用在服务器性能测试（关键点资源占用情况、数据库性能和故障报警、工具监控）。
• 软件部署模式：面向单机（脚本编程实现安装和注册）、集中式服务器（用户访问量小500下）、集群式服务器（并发访问量大10000上，对系统稳定和性能要求高的分布式平台部署）。
• 软件维护类型：改正型（修改缺陷或不足）、适应性（修改适应系统软硬件环境变化）、完善性（增删功能以适应业务变化）。

  维护成本：业务应用系统，维护费用与开发费用大体相当，嵌入式实时系统的维护费用是开发成本的四倍以上。

  • 软件再工程：重新构造或编写现有系统的部分或全部，不改变其功能。目的是使系统更易于维护，需要再构造和再文档化。
  • 逆向工程：是以复原软件的规格说明和设计为目标的软件分析过程。