软件工程概论期末知识点总结

软件工程知识点

PS：本文所对应教材为 Ian Sommerville 所著机械工业出版社出版的软件工程原书第九版。

一、软件工程概述

1. 什么是软件工程？

   软件工程是指一门指导软件开发与维护的工程科学，它把经过时间证明的有效管理技术和当前最好的软件开发技术方法结合起来，强调采用工程的概念、原理、技术和方法来开发与维护软件。

2. 软件产品分为哪两类？

   1. 通用软件产品
   2. 定制软件产品

3. 软件产品应该具有哪四个重要属性?

   可维护性、可依赖和安全性、有效性、可用性。

4. 软件工程方法学三要素：方法、工具和过程。

二、软件过程

1. 软件过程有哪四个基本活动？请列举并给出解释。

   1. 软件描述 – 必须定义软件的功能以及软件操作上的约束。
   2. 软件设计和实现 – 必须生产符合描述的软件。
   3. 软件有效性验证 – 软件必须得到有效性验证。
   4. 软件进化 – 软件必须进化以满足不断变化的客户需要。

2. 指出3种常见的软件过程模型，并说明应用场景，优缺点。

   1. 瀑布模型：在开发时间内需求不变化或变化较少的项目；分析设计人员对应用领域较熟悉的项目；低风险的项目;用户使用环境相对稳定的项目。优点：开发阶段清晰。 缺点：不可逆或很难可逆
   2. 增量式开发：在整个开发过程中，需求都可能发生变化，客户接受分阶段交付产品的项目；分析设计人员对应用领域不熟悉的项目；中高等风险项目；用户可参与到整个开发过程中的项目；使用面向对象语言或第四代语言开发的项目；大型软件系统。开发周期较长(超过1年)；分批投资的项目。 优点：降低适应用户需求变更的成本；更好的与用户对接完成用户需求；更早使用软件并创造商业价值。缺点：程序与迭代，敏捷过程不匹配。
   3. 面向复用的软件工程：该方法是基于已存在的大量可复用的组件。系统开发过程着重于集成这些组件到新系统中，而非从头开发。优点：减少需要开发的软件数量，降低了成本，风险。 缺点：组件更新不可控，对系统进化的控制失效。

3. 增量模型的优点？

   1. 项目可以分解为多个子系统，子系统之间边界清楚；
   2. 任务或功能模块驱动，可分阶段提交产品；
   3. 系统本身具有良好的模块化特征，模块内部高内聚，模块之间低耦合，模块本身信息隐蔽；

4. 增量模型的缺点？

   1. 不适合各部分联系紧密的项目；
   2. 系统整体结构的一致性可能较差；
   3. 各子系统风格可能不一致；

5. 应对系统需求变更的主要方法：

   1. 变更避免：软件过程包括一些能够在重大返工前预测变更的活动。
   2. 变更容忍：所设计的过程使得变更以相对较低的成本得到处理。

6. 各个应对变更方法的优缺点？

   • 原型构造优点：
     • 使客户了解最终产品的大致状况；
     • 使客户和开发人员深入理解项目的实质；
     • 共同讨论一些双方难以达成一致的部分；
     • 降低软件开发的风险。
   • 原型模型的缺点：
     • 由于有了一个原型产品，不利于开发人员的创新；
     • 开发进度可能难以控制。
   • 增量式交付优点：
     • 客户可以将早期的增量作为原型，从中获取需求经验；
     • 客户无需等到整个系统的实现才能从中获益；
     • 保持了增量开发的优点，更容易嵌入系统；
     • 最重要的部分被多次测试。
   • 增量式交付缺点：
     • 难以确定全体增量所需的公共设施；
     • 替换系统时，难以迭代开发；
     • 与大型机构签订匹配的合同有困难。
   • 螺旋模型优点：
     • 强调风险管理,开发大型软件时可降低风险。实际上是一个过程管理模型，而非开发模型；
     • 每一次循环可以采用不同的模型，适应风险变化。
   • 螺旋模型缺点：
     • 开发进度可能难以控制。

三、敏捷软件开发

1. 敏捷方法的基本原则是什么？

   客户参与，增量式交付，人非过程，拥抱变化，保持简洁。

2. XP 与 Scrum 的区别？

   1. 迭代长度的不同。Scrum 为两周到一个月；XP 则为一两周。
   2. 在迭代中，是否允许修改需求。Scrum 在一个sprint中不接受变更；XP 在用户故事规模、大小差不多的情况下，可用新的进行替换。
   3. 在迭代中，User Story 是否严格按照优先级别来实现。Scrum 自己决定任务完成顺序；XP 则会按照优先级完成。
   4. 软件的实施过程中，是否采用严格的工程方法，保证进度或者质量。

四、需求工程

1. 功能性需求和非功能性需求有什么区别？请分别说明请内涵。

   1. 功能需求：包括对系统应该提供的服务、如何对特殊输入做出反应，以及系统在特定条件下的行为的描述。在某些情况下,功能需求可能还需声明系统不应该做什么。
   2. 非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束和所受到的标准的约束。

2. 需求描述包括哪些主要方法，请说明优缺点。

   1. 自然语言，可以包含大量细节，但不形式标准，统计分析逻辑关系复杂的需求式工作量大。
   2. 结构化描述，简单明了，适合描述复杂的逻辑关系，但易缺失原始需求的细节。
   3. 用例，符合UML标准，适用性广，但需要配以脚本才能充分说明其需求。对用户来说理解上有一定难度。

五、系统建模

用例图、类图、时序图、活动图、状态图多看看，都是重点。

六、体系结构设计

1. MVC模式。

名字	MVC (Model-View-Controller)
描述	将表示和交互从系统数据中分离出来。系统被设计成由3个彼此交互的逻辑组件组成：模型组件管理系统数据和在数据上的操作，视图组件定义和管理如何显示数据给用户，控制器组件管理用户的交互，并传递这些交互给视图和模型。
实例	Figure 6.4 说明了采用MVC模式的基于web的应用系统的体系结构
使用时机	在数据有多个显示和交互方式的时候使用。也可在对未来数据的交互和表示需求不明确的时候使用。
优点	允许数据独立地独立，不影响表示，反之亦然。支持对相同数据的多种不同方式的表达，对某种表示的变更会传递到所有其他的表示。
缺点	可能需要额外的代码，当数据模型和交互很简单时代码的复杂度相对较高。

2. 分层体系结构。

名称	Layered architecture分层体系结构
描述	将系统组织成分层结构，每一层中包含一组相关的功能，每一层提供服务给紧邻的上一层。因此，最底层是有可能被整个系统所使用的核心服务。
实例	存在于不同的图书馆中的共享版权文档的系统分层模型。
使用时机	在已有系统的基础上构建新的设施时使用；当开发团队由多个分散的小团队组成，且每个小团队负责一层的功能时使用；或者当系统存在多层信息安全性需求时使用。
优点	允许在接口保持不变的条件下更换整个一层。在每一层中可以提供冗余服务以增加系统的可靠性。
缺点	在具体实践中，在各层之间提供一个干净的分离通常是困难的，高层可能不得不直接与低层进行直接交互而不是间接通过紧邻的下一层进行交互。性能可能是个问题，因为服务请求会在每一层中被处理，所以会需要多层解释。

3. 容器模式。

名称	容器Repository
描述	系统的所有数据在一个中央容器中管理，该中央容器可以被所有系统组件访问。组件间不是直接进行交互，它们只通过容器进行交互。
实例	Figure 6.9 是IDE的一个实例，组件使用一个系统设计信息的容器。每个软件工具生成信息放入容器，然后被其他工具所使用。
使用时机	当一个系统中所生成的大量信息需要持久保存时，可以使用该模式。也可以在数据驱动系统中使用该模式，每当在容器中收入数据时将触发一个动作或工具。
优点	组件是是独立的，它们无需知道其他组件的存在。一个组件的变更可以传播到所有的组件。所有的数据可以得到一致的管理，因为它们是存在一个地方。
缺点	容器是一个单个失败点，因而容器中的问题会影响整个系统。在组织所有通过容器进行的通信时会比较低效。将容器分布到多个计算机上会很困难。

4. 客户机-服务器模式。

名称	Client-server客户机-服务器
描述	在客户机-服务器体系结构中，系统的功能是以服务的形态存在的，每一个服务来自于某个单独的服务器。客户机是那些使用服务和访问服务器的用户。
实例	图 6.11 是一个电影和视频/DVD资料库，示例是以客户机-服务器形式存在的系统。
使用时机	当需要从很多地点访问共享数据时使用。因为服务器可以复制，所以也可以在系统负载经常变化时使用。
优点	该模型的主要优点是服务器可以分布到网络上。一般性的功能（例如打印服务）可以被所有的客户机使用，但并不需要被所有的服务所实现。
缺点	每个服务是单个失败点，所以对阻止拒绝服务攻击或服务器失败缺乏免疫性。性能也可能是无法预知的，因为它依赖于网络也依赖于系统。当服务器属于不同机构时，也存在管理方面的问题。

5. 管道和过滤器模式。

名称	管道和过滤器
描述	系统中数据的处理是这样组织的，每个处理组件（过滤器）都是分离的并执行某个类型的数据转换。数据流（如在一个管道中）从一个组件流向另一个组件。
实例	Figure 6.13是用于处理票据的管道和过滤器系统的例子。
使用时机	一般应用在数据处理应用中（批处理和事务处理），一些不同的阶段处理输入数据，并产生相应的输出。
优点	易于理解并支持变换的复用。工作流风格与很多业务处理体系结构很匹配。通过添加变换的方式进行进化是很显然的。可以实现为顺序的系统，也可以实现为并发的系统。
缺点	在通信变换间所传输的数据格式必须协商好。每个变换必须解析它的输入并写成约定的格式输出。这增加了系统的负荷，意味着不可能复用使用不兼容数据结构的函数变换。

七、设计和实现

1. 设计模式的分类？
   1. 创建型
   2. 结构型
   3. 行为型
2. 设计模式的四种主要元素？
   1. 名字，是模式的一个有意义的代指。
   2. 问题域的描述，解释什么时候模式可以应用。
   3. 对部分设计的解决方案描述，描述设计方案的各个部分及其之间的关系和职责。
   4. 结果陈述，说明应用该设计模式的结果及副作用。

八、软件测试

1. 一个商业软件要经过哪三个阶段的测试？
   1. 开发测试
   2. 发布测试
   3. 用户测试
2. 开发测试过程中的三个粒度级别测试分别是什么？
   1. 单元测试即对单独的程序单元或对象类进行测试。单元测试应该着重测试对象或方法的功能。
   2. 组件测试即将多个程序单元整合创建一个合成的组件。组件测试应该着重测试组件的接口。
   3. 系统测试即集成系统中的一些或所有组件作为一个整体进行测试。系统测试应该着重测试组件的交互。

九、软件进化

1. Lehman定律？

定律	描述
持续变更	避免程序失去在相应环境中的作用
不断增长的复杂性	需要额外资源来保持和简化结构
大型程序进化	程序进化是一个自我控制的过程
机构稳定性	在一个程序生命周期中，开发速度几乎为常数
保持亲密性	在一个系统生命周期中，版本变更增量接近常数
持续增长	功能需持续增加，以保证用户满意
降低质量	在运行环境中要不断适应变化
反馈系统	可取得效果显著的产品改善